I'm currently a developer assisting a small devops team to improve our code-to-infrastructure pipeline while making sure we're compliant with SOC2. We lack clear accountability for policy creation and implementation, which has led to confusion. I'm grappling with concepts like the "principle of least privilege" and understanding IAM binding, particularly in Google Cloud Platform (GCP). Right now, we've got a single GCP service account that has god-like permissions across all projects and environments. This has resulted in some serious production issues due to developers mistakenly using local terraform development in the wrong environments. My team and I are struggling to set up a better structure. Here are some of the things I'm pondering:
- Do you recommend keeping environments air-gapped so that no single service account has access to multiple environments?
- Should developers have the ability to deploy to development, sandbox, or test environments? What about having an emergency access mechanism for production in case of issues?
- Can developers manage service accounts and IAM permissions in their dev environments, and what about more critical resources like storage buckets?
- How can I allow developers access to the necessary project pipelines without giving them undue privilege that could threaten other parts of the infrastructure?
- If a microservice needs access to specific resources, how do I ensure it can create those without being able to manipulate unrelated services or resources?
Are these questions just nitpicking, or do they hold significant weight in ramping up compliance and security?
4 Answers
The maturity of your team and organization plays a huge role. If individual teams are accountable for their cloud resources, allowing them independence works well. Otherwise, things can quickly devolve.
We’ve established that DevOps builds frameworks for deployment while developers have the freedom to create within that framework. That way, we ensure things like least privilege and compliance are in place but still allow developers to work efficiently.
Does that also mean they need to go through a review process before new patterns are introduced?
Yes, we definitely keep our environments air-gapped. Each team gets their own landing zone with specific network and project setups. This helps keep things contained, and we have policies in place forbidding things like public IPs without approval.
What do you think air-gapped means?
This really helps clarify things for me! I’m starting to see that I need to gather the right people regularly to work on these compliance tasks together.
In our setup, DevOps manages IAM. Developers can modify only their specific resources and need to coordinate with other teams for anything outside that. This ensures no account can deploy everywhere without oversight.
How do you handle resource requests if they need something from another team? Do they just submit a request?
Exactly! It’s all about ensuring the right balance of control and autonomy.