Aembit Adds Jenkins CI/CD Support

Jenkins powers countless builds every day – but most pipelines still depend on static secrets. That ends today. We’re pleased to announce that the Aembit Workload IAM Platform now fully supports Jenkins as a server workload, delivering a secure, zero-trust approach to credential management for your CI/CD pipelines.

This addition continues our commitment to securing the entire software delivery lifecycle, joining our robust support for GitLab and GitHub CI/CD platforms. If your team relies on Jenkins, whether for complex pipelines or simple freestyle projects, you can now eliminate long-lived, static secrets and switch to automated, just-in-time credential access and injection.

The Credential Challenge in Traditional Jenkins

Historically, Jenkins, the leading open-source automation server, has relied on brittle and high-risk methods to access databases, clouds (AWS, Azure, GCP), and APIs.

How does Jenkins typically get the identity and credentials it needs?

• Jenkins Credentials Manager or External Vault: While centralizing secrets, these are often long-lived API keys or static passwords stored directly on the Jenkins server or an external vault. If the server is compromised, all these secrets are exposed.
• Environment Variables: Adding secrets directly into the pipeline script as environment variables, which are easily logged or exposed.
• Configuration Files: Storing credentials in files, which is arguably the least secure method.

All these methods share a critical flaw: they use static, long-lived credentials that continue to be the source of numerous leaks and breaches.

Unleashing Zero Trust with OIDC Tokens

Aembit flips this model by utilizing OpenID Connect (OIDC) tokens issued directly by your Jenkins instance. This is the heart of our new integration, providing a cryptographically verifiable identity for every job run.

Here’s how it works:

1. Identity Assertion: A Jenkins job, via the OIDC provider plugin, mints a short-lived, cryptographically signed OIDC ID token. This token contains claims (like job name, branch, and project path) that assert the job’s identity.
2. Aembit Trust: You configure an OIDC ID token trust provider in Aembit to trust tokens from your Jenkins base URL (the issuer).
3. Just-in-Time Access: When your pipeline runs the Aembit CLI, it presents the Jenkins OIDC token. Aembit verifies the token’s signature, validates the claims against the configured access policy (e.g., “Only job ‘deploy-prod’ on branch ‘main’ can do this”), and then exchanges the token for temporary, short-lived credentials (like an AWS STS token or a HashiCorp Vault token).

This eliminates the need to store static secrets anywhere in your Jenkins environment, dramatically improving your security posture.

Flexible Deployment: Supporting Self-Hosted and Cloud Jenkins

One of the great strengths of Jenkins is its deployment flexibility – it can run almost anywhere. Our new support is designed to work across these environments, including crucial self-hosted Jenkins deployments.

For Aembit to successfully verify the OIDC tokens, your Jenkins instance needs to follow one critical rule: The Jenkins URL (the issuer) must be a publicly accessible domain name. Aembit uses this URL to retrieve the public keys (from the JWKS endpoint) needed to validate the token’s signature. This setup ensures that whether you run Jenkins on-premises, in a containerized environment, or on a cloud VM, the security mechanism remains consistent and robust.

A Better Experience: Less Code, Zero Secret Anxiety

The shift to OIDC-based authentication doesn’t just improve security; it radically simplifies the daily workflow for both developers and DevOps engineers.

For the Developer: Focus on Code, Not Credentials

In traditional environments, a developer building a Jenkins pipeline had to address several tedious and risky steps:

• Secret Sourcing: Requesting or generating a long-lived secret (API key, service account JSON, or password) from a security team or cloud console.
• Pipeline Code Complexity: Writing extensive, boilerplate pipeline code just to retrieve a secret from the Jenkins credentials store, decrypt it, inject it into an environment variable, and then ensure it’s masked or cleaned up afterward.
• Rotation Burden: Manually updating pipeline code or Jenkins configurations whenever a secret was rotated.

With Aembit, this complexity is replaced by a single, simple command. The pipeline’s only job is to assert its identity via the OIDC token, and Aembit handles the rest. This means less boilerplate code, cleaner Jenkinsfiles, and more time spent on feature development, not security plumbing.

For the DevOps Engineer: Control, Auditing, and Zero Rotation

For the DevOps team, Aembit replaces the administrative burden of managing long-lived secrets with centralized policy enforcement:

• Policy, Not Credentials: DevOps engineers no longer need to provision static API keys or cloud service accounts for CI jobs. Instead, they define a policy in Aembit that says which specific Jenkins job is allowed to assume which role to access which service.
• No Rotation Headaches: Since Aembit issues short-lived, just-in-time credentials for every job run, the need for manual secret rotation is completely eliminated. The credentials expire naturally, drastically reducing the window for a compromise.
• Centralized Auditing: Every credential request and issuance is logged and auditable in Aembit, providing a single source of truth for who accessed what, when, and with what authorization. This improves compliance and significantly speeds up security investigations.

By automating credential management entirely, Aembit allows developers to deliver faster and DevOps teams to enforce zero trust with less effort.

Configuration at a Glance

Getting started is fast and requires just a few steps, highlighting our flexibility to support both Jenkins pipelines and freestyle projects:

1. In Jenkins:
   • Install the Open ID Connect provider plugin.
   • Configure your Jenkins system settings to use a publicly accessible Jenkins URL.
   • Create an OpenID Connect id token credential in the Jenkins Credentials Manager.
2. In Aembit:
   • Create an OIDC ID token trust provider, specifying your Jenkins URL as the issuer.
   • Configure a client workload and access policy to define what your Jenkins jobs are allowed to access and what temporary credentials they should receive.
3. In the Job:
   • In your pipeline script or freestyle project build step, use the ‘aembit credentials get’ command, passing the automatically-injected OIDC token to receive dynamic credentials.

Find detailed configuration steps here. 

Summary and Call to Action

The integration of Jenkins as a secure server workload extends Aembit’s vision for comprehensive CI/CD pipeline security. By leveraging OIDC tokens, we enable secure, auditable, and just-in-time credential access, eliminating the static secret problem that has plagued DevOps teams for years. This flexible solution works seamlessly whether you are using traditional freestyle projects or modern declarative pipelines. It can upgrade your pipeline security without breaking any existing Jenkins configuration or pipelines.

Stop manually rotating secrets and start adopting a Zero Trust credential posture for your Jenkins environment today.

Ready to secure your Jenkins pipelines? Try Aembit today!