For years, Jenkins pipelines have relied on long-lived access keys, service account tokens, and stored username/password combinations to reach cloud resources. These static secrets create an ongoing security burden: they sit in Jenkins credentials storage, get copied into environment variables, and often outlive the employees who created them. To break this pattern, more teams are adopting OIDC (OpenID Connect) federation. The core idea is simple: use OIDC to eliminate CI/CD static credentials in Jenkins by delegating authentication to cloud providers. This approach removes long-lived secret storage entirely, replacing it with short-lived, context-aware tokens generated on demand.
The Problem with Long-Lived Secrets in Jenkins
Storing cloud provider credentials directly inside Jenkins is a common convenience, but it comes with hidden costs. Every static secret represents a potential blast radius. If a Jenkins configuration is exfiltrated via a plugin vulnerability, or a job log accidentally prints an access key, an attacker can use those credentials until they are manually rotated and revoked. In many environments, rotation is a slow, error-prone process—especially when the same credentials are shared across projects or teams.
Static credentials also complicate compliance. Auditors increasingly expect organizations to enforce least-privilege access and demonstrate that humans and machines authenticate with temporary, verifiable identities. Hardcoded or stored cloud credentials can fail these expectations. The result is a recurring cycle of secret inventory, rotation pain, and incident response—none of which adds value to your delivery pipeline.
How OIDC-Based Workload Identity Works in Jenkins
OIDC-based workload identity flips the model. Instead of Jenkins possessing a static secret that can access the cloud, Jenkins acts as an OIDC token issuer. When a pipeline job starts, it requests a short-lived identity token. That token is sent to the cloud provider—AWS, Microsoft Azure, Google Cloud, or another OIDC-aware service—where it is verified against a preconfigured trust relationship. The cloud provider then exchanges the token for its own temporary cloud credentials, which are valid for a short period such as one hour or less.
This approach removes the need to store a cloud secret in Jenkins. The cloud provider never sees a long-lived access key emitted by Jenkins. Instead, it sees a cryptographically signed JWT (JSON Web Token) that includes claims about the Jenkins job, branch, repository, or organization. The provider applies an IAM role or service account policy based on those claims, ensuring that each pipeline run receives exactly the permissions it needs—no more, no less.
The OIDC federation flow at a glance
- Jenkins generates an OIDC token for a specific pipeline run using its configured issuer URL and audience.
- The pipeline submits the token to the cloud provider’s identity federation endpoint.
- The cloud provider validates the token’s signature, issuer, audience, and subject claims.
- The provider maps the token to a predefined IAM role or workload identity.
- Temporary cloud credentials are returned to the Jenkins agent and used for that build only.
Setting Up Jenkins OIDC Federation with Cloud Providers
Every major cloud provider supports OIDC federation, but the configuration differs slightly. The good news is that Jenkins can act as a platform-agnostic OIDC issuer through plugins like the OIDC Provider Plugin, or by using a reverse proxy that exposes a token endpoint. Once your Jenkins instance can issue OIDC tokens, you wire the trust to each cloud provider.
AWS: Trusting Jenkins as an OIDC issuer
In AWS, you create an OpenID Connect identity provider in IAM. You add the Jenkins OIDC issuer URL and audience, then create a role with a trust policy that allows the OIDC provider to assume the role. The trust policy uses conditions like sub matching repo:my-org/my-repo:ref:refs/heads/main to restrict which pipelines can assume which role. In your Jenkinsfile, you request the token via an HTTP call and then call aws sts assume-role-with-web-identity to get the temporary credentials.
Azure: Using federated workload identity
For Azure, you configure a federated identity credential on a user-assigned managed identity or app registration. The federated credential specifies the Jenkins OIDC issuer URL, an audience, and a subject identifier. At runtime, your pipeline obtains an OIDC token from Jenkins and exchanges it for an Azure access token using the Microsoft Identity Platform’s token endpoint. The result is the same: temporary, scoped credentials with no service principal secret stored in Jenkins.
Google Cloud: Workload identity federation
Google Cloud supports workload identity federation by allowing you to create a workload identity pool and provider for your Jenkins issuer. The provider details include the issuer URL and the OIDC subject attribute. After your pipeline obtains an OIDC token, it calls the Security Token Service to exchange that token for a temporary Google Cloud access token. Your pipelines use the token to authenticate with Cloud SDK commands, eliminating service account key files.
Best Practices for a Credential-Less Jenkins Pipeline
Moving to OIDC federation is not a magic button; it requires thoughtful design. The following practices will help you build a pipeline that is both secure and maintainable.
- Use precise subject claims. Configure your OIDC provider plugin to include meaningful subject claims such as the repository name, branch, or job path. The more granular the claim, the narrower the trust boundary.
- Scope each role to a single environment. A pipeline running on the main branch should assume a role with production permissions, while a pull request build should assume a read-only or sandbox role.
- Shorten token lifetimes. Set your OIDC token expiration to the minimum value that still allows the build to complete. This reduces the window in which a stolen token can be replayed.
- Avoid exporting the token to logs. Mask OIDC tokens and cloud credentials in Jenkins console output using the Mask Passwords plugin or the built-in secret handling.
- Audit OIDC usage continuously. Monitor CloudTrail, Azure Activity Log, or Cloud Audit Logs to detect unexpected role assumption patterns and unauthorized token exchanges.
- Plan for provider drift. Regularly review the OIDC provider configuration and IAM trust policies to ensure they still match your repository structure and team permissions.
Real-World Benefits Beyond Removing Static Secrets
The obvious win is that your Jenkins instance no longer stores cloud credentials. But there are deeper benefits that reshape how teams think about CI/CD security.
First, auditability improves dramatically. Every pipeline run can be traced to a specific OIDC token with unique claims, which maps to a single job and execution. Security teams can answer the question, “Which build assumed this role, and why?” without searching for shared secrets.
Second, incident response becomes faster. If a repository is compromised, you revoke trust by updating the OIDC subject conditions or deleting the IAM role—no need to rotate dozens of long-lived keys. That revocation is global and immediate, not dependent on when an engineer next checks the Jenkins credential store.
Third, onboarding becomes simpler. Teams no longer need to request cloud credentials from an operations group when they start a new Jenkins project. They only need the OIDC provider configured and a role with the right trust policy. This reduces friction and encourages a security-first workflow where each project receives its own least-privilege identity.
Finally, OIDC federation aligns with broader zero-trust initiatives. It enforces the principle that all access, including machine-to-machine communication, is authenticated and authorized in real time. The cloud provider remains the authoritative identity source, while Jenkins merely proves which workload is running. This reduces the overall credential surface area and lets security teams focus on policy rather than secret rotation.
Conclusion
Eliminating static credentials from Jenkins is no longer an aspirational architecture. With OIDC federation, your pipelines can authenticate directly to AWS, Azure, or Google Cloud using short-lived tokens generated by Jenkins and verified by the cloud provider. By using OIDC to eliminate CI/CD static credentials in Jenkins, you remove the need for long-lived secret storage, shrink the risk of credential leakage, and build a more transparent, auditable delivery process. The shift to workload identity may require an initial configuration effort, but the payoff is a CI/CD environment that is fundamentally more secure and far easier to operate.
