Skip to content
Notifications
Clear all

Check out what I made: A Terraform module for managing Banyan resources.

9 Posts
8 Users
0 Reactions
2 Views
(@emmam4)
Estimable Member
Joined: 2 months ago
Posts: 114
Topic starter   [#29034]

Hey everyone! I'm pretty new to infrastructure-as-code stuff, but I've been playing with Banyan's free tier for securing a few internal tools.

I kept setting up the same policies for different test services, so I tried making a Terraform module to handle it. It basically sets up a service and trust score policy together. This is my first real Terraform thing, so it's probably super basic, but it saved me a ton of clicking in the portal!

Wanted to share in case it helps anyone else who's starting out. Has anyone else tried automating Banyan setup? I'd love to see how others are doing it.



   
Quote
(@benjaminc)
Reputable Member
Joined: 2 months ago
Posts: 246
 

That's awesome. Automating the portal clicks is exactly what I'd want to do. Did you run into any tricky parts with the Banyan provider itself, like missing fields or docs? I'm curious how stable the Terraform support is before I rely on it.



   
ReplyQuote
(@bent36)
Estimable Member
Joined: 2 months ago
Posts: 114
 

That's a great use case. I've been thinking about how to handle reusable policies across teams. Does your module let you tag the resources it creates? That would help with organizing things later.



   
ReplyQuote
(@infra_architect_rebel)
Honorable Member
Joined: 5 months ago
Posts: 544
 

Saving clicks is good. But you're just moving complexity from the portal into a module.

Why do you need a custom policy per service? That's how you end up with 200 policies nobody understands.

Default deny. One common policy. Done.


Simplicity is the ultimate sophistication


   
ReplyQuote
(@alexm82)
Reputable Member
Joined: 3 months ago
Posts: 255
 

That's a fair point about policy sprawl. But don't you run into issues when different services need different access rules? Like, our finance tool needs stricter rules than the internal wiki.

How do you handle exceptions with one common policy? Do you just make it more permissive and accept the risk?



   
ReplyQuote
(@davidm78)
Reputable Member
Joined: 3 months ago
Posts: 351
 

Great question. That's the exact tension we wrestle with.

We ended up with a small set of *policy templates*, not one universal one. Think "finance-grade", "engineering-internal", "all-hands-readonly". Each template defines its own trust score requirements and access hours.

Then our Terraform modules just reference the right template. Keeps the policy count low but still lets us lock down the finance tool more than the wiki. We tag everything with the template name for reporting. Works pretty well so far.


Data doesn't lie, but dashboards sometimes do.


   
ReplyQuote
(@alexm82)
Reputable Member
Joined: 3 months ago
Posts: 255
 

That's a good point about tagging. I haven't looked at tagging in the Banyan provider yet. Can you actually apply tags to a service or a policy directly through Terraform, or is that something you have to do later in their console? I'm worried about splitting configuration between code and the portal.



   
ReplyQuote
(@chloe22)
Honorable Member
Joined: 3 months ago
Posts: 503
 

Yep, the provider supports tags for both services and policies as a `tags = {}` block, so you can set it all in the same Terraform run. I think they added that around provider version 1.5.

That said, I'd double-check the tag keys you're using match what your team or org already uses for reporting. It's easy to create a new tag in Terraform that doesn't sync with your existing cloud governance tags, and then you're back to managing things in two places.


Raise the signal, lower the noise.


   
ReplyQuote
(@george7)
Honorable Member
Joined: 3 months ago
Posts: 572
 

Great to see someone automating those repetitive portal clicks. It's a smart first step, and a lot of people start that way.

I'd echo what others said about thinking ahead to policy sprawl. That "saving a ton of clicking" feeling is a real win, but it's also what can quietly create a management headache later. Tagging from the start, as mentioned, is a good habit.


Keep it constructive.


   
ReplyQuote