Zero secrets in pipelines — and why most teams still get this wrong
Go check your CI/CD pipelines right now. Count the stored secrets. Service principal credentials, container registry passwords, SSH keys, API tokens, all sitting in pipeline variables. Sometimes encrypted, sometimes not.
Now ask yourself: when was the last time you rotated them?
If you’re being honest, the answer is probably “when one of them expired and the pipeline broke at the worst possible time.” I know because that was my answer too, for years.
The secret sprawl problem
Here’s how it starts. You need your Azure DevOps pipeline to deploy to a Kubernetes cluster. You create a service principal, generate a secret, and store it in the pipeline variables. It works. You move on.
Six months later, you have 15 pipelines across 8 repos, each with their own set of credentials. Some share service principals. Some have credentials you copied from a colleague’s pipeline because it was faster than understanding the permission model. Some have secrets that were “temporary” and have been in production for two years.
This isn’t a security risk in theory. It’s a security risk in practice. Stored credentials are static, long-lived, and broadly scoped. They’re the most common vector for supply chain attacks in CI/CD systems. Rotating them is painful enough that nobody does it until something breaks.
The alternative: identity federation
Azure Workload Identity federation changes the model. Instead of storing a credential that proves the pipeline is authorized, you establish a trust relationship where Azure verifies the pipeline’s identity directly.
The concept is simple. Your Azure DevOps pipeline has an identity (an OIDC token issued by Azure DevOps). Your Azure resources have a trust policy that says “I trust tokens from this specific pipeline in this specific project.” When the pipeline runs, it presents its token, Azure validates it, and no stored secret is involved.
The result: zero credentials stored in your pipeline variables. Not “encrypted credentials.” Not “credentials in a vault.” Zero.
What this looks like in practice
In my Azure DevOps setup, the pipeline configuration looks roughly like this:
The pipeline requests a federated token from Azure DevOps. Azure AD validates the token’s issuer (Azure DevOps), subject (the specific service connection), and audience (Azure Resource Manager). If all match the trust policy on the managed identity, Azure issues a short-lived access token.
Key properties of this approach:
There are no credentials to rotate. The trust relationship is based on identity verification, not shared secrets. Nothing expires unexpectedly at 3 AM.
The trust policy is scoped by default. It specifies exactly which pipeline, in which project, can assume which identity. A compromised pipeline in one project cannot escalate to resources trusted by another.
The access tokens Azure issues are short-lived, valid for minutes rather than months. Even if intercepted, the window for misuse is minimal.
Every token exchange is logged and auditable. You can trace exactly which pipeline accessed which resource, when, and from which run.
Where teams get stuck
The migration from stored secrets to workload identity isn’t technically hard. It’s organizationally hard. Here’s what I see:
“We’ll migrate when we have time.” You won’t. There’s never time. The migration has to be treated as a security requirement, not a nice-to-have. Every month you delay is another month of unrotated credentials.
“Our pipelines are too complex to change.” Usually this means the pipeline has accumulated so many implicit credential dependencies that nobody fully understands what has access to what. That complexity is the vulnerability, not a reason to wait.
“We use a vault for our secrets.” Vaults solve the storage problem but not the existence problem. A secret in HashiCorp Vault is still a secret that can be exfiltrated, still needs rotation, and still represents a static trust relationship. Workload Identity eliminates the secret entirely. There’s nothing to steal.
The migration path
For teams currently drowning in pipeline secrets, here’s how I approach the migration:
Inventory. List every stored credential across all pipelines. Categorize by what it accesses: Azure resources, container registries, external services. This is usually the most sobering step.
Prioritize by blast radius. Credentials that access production subscriptions or container registries go first. A compromised deployment credential is worse than a compromised notification webhook token.
Create managed identities with minimal scope. One identity per logical workload, not one identity per pipeline. Scope the RBAC role assignments to the exact resources needed. “Contributor on the subscription” is not an acceptable scope.
Establish federated credentials. Configure the trust relationship between Azure DevOps service connections and the managed identities. Test in a non-production pipeline first.
Delete the stored secrets. Not “disable.” Delete. If the old credentials still exist, someone will use them when the new approach feels unfamiliar. Remove the escape hatch.
Why this matters beyond security
Zero secrets in pipelines isn’t just about security hygiene. It’s about building infrastructure you can actually trust. When every deployment relies on stored credentials, you’re building on static trust assumptions that degrade over time. Credentials get over-scoped. Rotation gets deferred. Knowledge of what has access to what gets lost.
Workload Identity federation replaces that with dynamic trust verification. The pipeline proves who it is every time and receives exactly the access it needs for exactly as long as it needs it.
It’s more work to set up than copying a service principal secret into a pipeline variable. But the next time a credential expires in production on a Friday evening, you’ll wish you’d done it sooner.