In this lesson, you will learn how to implement granular security for your registry interactions by using scoped service accounts and environment-specific credentials to prevent privilege escalation in your CI/CD pipelines.
When building or deploying containers, giving a CI/CD runner broad, admin-level access to your private container registry is a significant security risk. If a pipeline is compromised, an attacker could potentially delete production images or access unauthorized repositories. To mitigate this, we move away from global service account tokens and toward the principle of least privilege.
Scoped Service Accounts
Instead of a single "CI-User," create dedicated service accounts for specific workflows. For example, a "Builder" account should have push permissions for your staging registry, while a "Deployer" account in your production cluster should have only pull (read-only) access to the production registry.
In Kubernetes, you represent this by creating a secret of type kubernetes.io/dockerconfigjson. You inject this into your runner's execution environment so the container runtime can authenticate without exposing raw credentials in your Dockerfile or pipeline scripts.
Environment-Specific Credentials
By separating credentials by environment, you ensure that a misconfigured dev pipeline cannot overwrite images in a production repository. You store these secrets within your CI/CD tool’s secret manager (e.g., GitHub Secrets, GitLab CI Variables) and map them to specific pipeline stages:
# Example: Mapping a secret to a specific environment job
deploy-prod:
stage: deploy
environment: production
script:
- docker login -u $REGISTRY_USER -p $REGISTRY_PASSWORD $REGISTRY_URL
- kubectl set image deployment/app app=$IMAGE_TAG
only:
- main
By decoupling the credentials, you ensure that the deploy-prod job uses a scoped token that is physically incapable of pushing new images, enforcing a unidirectional flow from your CI build system to your CD orchestration engine. This architecture ensures that even if one pipeline stage is compromised, the blast radius is contained by the limited scope of the injected identity.
Key Takeaway: Always enforce the principle of least privilege by using scoped service accounts and environment-specific credentials to strictly separate push and pull capabilities within your CI/CD pipeline.