Why pipelines are the highest-leverage identity in your org
CI/CD systems often hold the keys to production: they build artifacts, push containers, deploy infrastructure, and can change policy. That means “pipeline identity” is not just another non-human identity; it’s a meta-identity that can mint or modify many others.
Distinguish runner identity from job identity
A runner (agent, executor) is the long-lived compute that executes jobs, while a job is an ephemeral unit of work. If you grant the runner broad permissions, every job inherits them implicitly, which turns multi-tenant pipelines into a lateral-movement playground.
Prefer ephemeral, per-job credentials
Issue short-lived credentials per job execution, ideally scoped to the repo, environment, and stage. If you must use static secrets (legacy systems), constrain them to the smallest blast radius and set a migration path to dynamic issuance.
OIDC for CI/CD is the modern default
Many CI providers can present an OIDC token representing the job context, which your cloud/IAM system can exchange for short-lived role credentials. This eliminates stored cloud keys in CI variables and enables better audit trails because the job identity is embedded in claims.
Token exchange patterns for multi-step workflows
Complex pipelines often need to call multiple systems (artifact registry, deploy system, IaC backend). Use token exchange so each step gets a token with the right audience and scope, instead of passing one “super token” down the chain. (See Workload OAuth and Token Exchange.)
Signing and provenance: identity for artifacts, not just calls
Pipeline identity should also sign outputs: container images, SBOMs, attestations, and release bundles. Tie the signature to job identity and repository state so production only accepts artifacts from trusted pipelines and approved branches.
Secrets handling: avoid turning CI logs into a credential leak
Masking is not a security boundary; treat logs as hostile. Use dynamic secrets, avoid printing env vars, and ensure build tooling doesn’t echo tokens. For high-risk jobs, bind tokens to short TTLs and narrow audiences.
Authorization: map pipeline roles to environments explicitly
Define clear roles like “can deploy to staging” vs “can deploy to production,” and ensure promotion requires an independent check (approval, policy, or separate identity). This prevents a compromised dev pipeline from becoming a production deployer.
Integration with IaC and deploy systems
Your pipeline should authenticate to IaC backends and deploy controllers with identities that reflect intent (plan vs apply, staging vs prod). This aligns neatly with policy engines and reduces the temptation to reuse one credential across everything. (See Infrastructure-as-Code Identity.)