CI/CD and the Principle of Least Privilege
Treat your CI/CD pipeline like a temporary worker, not a superuser. Grant it only the minimum permissions needed for its specific task, like building code or deploying to staging.
Why it exists
Automated CI/CD pipelines are powerful, connecting your source code directly to your production infrastructure. If compromised, they offer a high-speed lane for an attacker to inject malicious code or exfiltrate data. The Principle of Least Privilege (PoLP) was created to contain the damage of such a breach by ensuring any single compromised component has very limited power.
The mental model
Think of your CI/CD pipeline not as a trusted employee, but as a series of single-task robots. Each robot (or job) gets a unique key that only opens the one door it needs for its specific task, and the key expires the moment the task is done. A robot that fetches dependencies doesn't get the key to the deployment door.
How it works
PoLP is implemented by granting narrowly-scoped, short-lived credentials to each stage of your pipeline. Instead of one powerful service account for the entire pipeline, you use different roles for different jobs. For cloud environments, this means using distinct Identity and Access Management (IAM) roles. For Kubernetes, it means separate service accounts for each job, bound to roles with minimal permissions. The goal is to reduce the "attack surface" (fewer entry points) and limit the "blast radius" (less damage if an entry point is breached).
When to use it
Use this principle for every automated process, especially in CI/CD. Any job that builds, tests, scans, or deploys code should run with the absolute minimum set of permissions required to complete its task. This applies to the runner itself (don't run as root), its access to cloud APIs, and its permissions within your container orchestrator or target servers.
When not to use it
There is no production scenario where ignoring this principle is a good idea. The primary reason people avoid it is for convenience during initial setup; granting admin-level access is faster than defining granular permissions. This is a dangerous trade-off that exchanges a few hours of configuration work for a massive, permanent security liability.
One canonical example
A pipeline deploys a web app to Kubernetes. A poor setup uses a single credential with cluster-admin rights for all jobs. A PoLP-compliant setup would have three distinct jobs with separate, temporary credentials: first, a 'build' job gets a token that only allows it to push a container to a specific registry; second, a 'deploy-staging' job gets a token for a Kubernetes service account that can only update deployments in the 'staging' namespace; third, a 'deploy-prod' job, often manually triggered, gets a token for a different service account that can only update deployments in the 'production' namespace. A compromise of the build stage cannot affect any Kubernetes cluster.
Interview question
What is the primary security benefit of implementing the Principle of Least Privilege in CI/CD pipelines?
- a.It ensures faster execution of pipeline stages by reducing permission checks.
- b.It guarantees that all stages have uniform access to all necessary production resources.
- c.It limits the potential damage if a single pipeline stage is compromised.Correct
- d.It simplifies the overall management of access credentials across the pipeline.
Why? this is the answer
The card states PoLP was created to "contain the damage of such a breach" and "limit the 'blast radius'" if a component is compromised. Option D is incorrect because PoLP often increases the granularity of credential management, making initial setup more complex, not simpler.
Just read this? Test yourself on what you have been reading.
Read the original → owasp.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on security — each one lists the topics its interview covers.
See open roles