Hey everyone! I'm exploring an idea that could change the way developers interact with cloud resources. The problem is that in many organizations, when developers need access to different environments (like dev, staging, or production) or specific cloud services, they have to ask cloud admins for permission. This process often creates delays and bottlenecks, making teams less autonomous.
So, here's my idea: What if developers could self-serve their cloud access via GitHub Pull Requests? Here's how it would work:
1. Open a GitHub Pull Request.
2. Fill out a simple YAML file specifying the access they need, the environment, and their role.
3. The PR would be reviewed and approved by a team lead.
4. A GitHub Action would automatically run Terraform to grant access.
5. Optionally, the access could auto-expire after a set period.
Basically, it would be 'Access as Code', allowing for a GitOps-native approach.
Why do I think this could work?
- Developers spend a lot of time in GitHub.
- Access requests would go through a standard code review.
- It offers full auditability.
- No more "please grant me access" tickets!
- The system would be versatile across AWS, Azure, and GCP.
I'm thinking of creating both a self-hosted open-source version with basic features and a SaaS offering with more enterprise-level options. I'd love your candid thoughts—would you use something like this? What would hold you back? Anything you think is missing?
6 Answers
Any self-service approach that maintains safety is a win. I’d recommend ensuring your pipeline includes checks and testing workflows before applying any changes.
In theory, this sounds like a great idea, but implementing it could be quite the challenge. I wouldn’t want to be the one handling the development! Still, if it could save time, I see its potential.
I've successfully set up something similar using Atlantis, and it wasn't too hard. The main issue I see is that many developers might still prefer to just put in a ticket rather than write YAML.
Implementation could be complex, but having more self-service options would be beneficial in the long run.
That's how we do it! We push code which triggers a Terraform plan, and admins can approve it before it gets applied. It took me only about 30 minutes to set it up, and it still works perfectly after three years.
Nice! It would be great if you could create a setup that allows easier adoption of both self-hosted and SaaS models.
That sounds efficient! I’m curious if you faced any challenges when implementing this?
Consider defining what specific problems you're trying to solve first. If teams own their environments, they should have permanent access to DEV and UAT, but for PROD, access should be more controlled. In my opinion, elevated access should be reserved for specific situations with stricter controls in place.
Absolutely! We've adapted that approach, granting devs more access to lower environments while keeping production more restricted.
I disagree about giving devs full access to UAT. It belongs to QA, and we need to maintain strict testing environments!
I built something like this for GitLab! Users submit a YAML similar to this format, and we utilize Python to handle the permissions. It was a quick build and works well. But, ensuring users know the permissions they need could be a hurdle; they might just end up needing help anyway.
This approach appears efficient, but it requires users to understand the permission structure they need, which might not always happen.
True! It could easily lead to back-and-forths and confusion if users aren't clear on what they need.
Using PRs for Terraform changes in production is definitely a best practice. It allows for a more controlled and auditable process.
Agreed! Including sanity checks is essential when granting permissions to avoid issues later.