CI/CD and the Principle of Least Privilege

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.