I've been exploring CI/CD setups lately and noticed that many teams allow their CI pipelines to deploy directly to production or hold significant cloud roles. This often happens not because it was planned that way, but because restricting automation can lead to broken builds or slow down development. I'm curious to know what permissions your CI pipelines actually operate with. How do you balance the need for permissions against security concerns?
3 Answers
I get where you're coming from! CI definitely needs permissions to deploy; otherwise, it defeats the purpose of continuous deployment. But I'm more interested in how much authority these pipeline identities actually have. In my experience, CI identities often have overly broad permissions, like the ability to modify infrastructure or touch multiple environments, just to keep things running smoothly. How do others manage that trade-off? Do you stick with broad roles or try to limit them?
Using GitOps here! My CI system has permissions to write to the GitOps repo and use OIDC for AWS auth to push images to ECR. Just a thought: with GitOps, the deploy authority shifts to the controller like Argo or Flux. Does anyone else manage their controller's permissions tightly, or do they tend to give it broader access right off the bat?
That's a good point! I wonder how many teams revisit the permissions for their controllers. I've seen some grow really broad without much management, which is definitely risky.
We try to keep it simple by granting our CI pipeline only the minimum required permissions for deploying applications to our Kubernetes clusters. Each pipeline has a unique identity too, so it can only deploy a specific app. That way, we reduce the risk of over-permissioning.
Absolutely, keeping those permissions in check is crucial. I've found that teams usually start with minimal permissions but often find themselves expanding them over time due to evolving needs.