Integrating Ephemeral Certificates and OIDC Identity into CI/CD Workflows

The integration of Public Key Infrastructure (PKI) and certificate management into Continuous Integration and Continuous Deployment (CI/CD) pipelines has fundamentally shifted. Driven by the exponential growth of machine identities—which now outnumber human identities by a staggering 45 to 1—and the impending reduction of public TLS certificate lifespans to 90 days, manual certificate provisioning is no longer a viable operational strategy.

Modern CI/CD pipelines must operate under Zero Trust principles, treating the build environment as inherently hostile. Injecting long-lived private keys or static credentials into a pipeline runner creates an unacceptable attack surface. Instead, infrastructure and security teams are moving toward dynamic, ephemeral certificate architectures that rely on OpenID Connect (OIDC), shift-left provisioning, and keyless code signing.

This article details the technical implementation of modern certificate integration within CI/CD pipelines, addressing the "Secret Zero" dilemma, automating TLS deployment in Kubernetes, and securing the software supply chain against cryptographic compromise.

Solving the "Secret Zero" Dilemma with OIDC

The most pervasive vulnerability in legacy CI/CD pipelines is the "Secret Zero" problem. To fetch a certificate, database password, or API key from a secure vault (like HashiCorp Vault or AWS Secrets Manager), the pipeline runner requires an initial credential to authenticate itself. If this initial credential is a long-lived, hardcoded token stored in the CI platform's environment variables, it becomes a high-value target for attackers. If the CI platform is compromised, Secret Zero is compromised, granting access to the entire vault.

The modern solution is Workload Identity Federation using OpenID Connect (OIDC). Instead of storing static credentials, the pipeline uses its cryptographic identity to request a short-lived, dynamically generated token from the cloud provider or secret manager.

When a pipeline job initiates, the CI platform (acting as the OIDC Identity Provider) generates a JSON Web Token (JWT) signed by its own private key. This token contains claims about the specific repository, branch, and workflow triggering the run. The cloud provider validates the JWT signature and, if the claims match a pre-configured IAM trust policy, issues a temporary session token.

Implementation Example: GitHub Actions to AWS

In a modern GitHub Actions workflow deploying to AWS, you no longer store AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Instead, you configure an AWS IAM OIDC Identity Provider and establish a trust relationship.

The pipeline implementation looks like this:

name: Deploy and Provision Certificates
on:
  push:
    branches: [ "main" ]

permissions:
  # Required to request the OIDC JWT from GitHub
  id-token: write 
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Configure AWS Credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-cd-deployment-role
          aws-region: us-east-1

      - name: Fetch Private Key from Secrets Manager
        run: |
          aws secretsmanager get-secret-value \
            --secret-id production/api/tls-key \
            --query SecretString --output text > private.key

Because the temporary AWS STS token expires shortly after the job completes, an attacker who compromises the build logs or the runner environment after the fact gains nothing. This same OIDC mechanism integrates natively with HashiCorp Vault, allowing pipelines to authenticate via the JWT auth method and dynamically generate short-lived X.509 certificates from Vault's PKI secrets engine.

Shift-Left Certificate Management for Infrastructure as Code

A frequent cause of catastrophic application downtime is the disconnect between infrastructure deployment and certificate lifecycle management. Historically, CI/CD pipelines deployed the application, and a separate process (or worse, a human operator) provisioned the TLS certificate. This disjointed approach has led to high-profile outages at organizations like Epic Games and Cisco Meraki when unmonitored certificates expired.

To prevent certificate-driven outages, certificate management must "shift left" and become an intrinsic part of the Infrastructure as Code (IaC). In Kubernetes environments, this is achieved by decoupling certificate generation from the CI/CD pipeline itself, delegating it instead to cluster-level operators within a GitOps workflow.

GitOps and cert-manager Integration

Rather than having a Jenkins or GitLab pipeline run OpenSSL commands, generate keys, and push them to Kubernetes via kubectl, the pipeline should only commit declarative configuration files to a Git repository. A GitOps controller (like ArgoCD or Flux) synchronizes these manifests to the cluster, where cert-manager takes over.

Here is an example of a Certificate Custom Resource Definition (CRD) that the CI/CD pipeline would test, validate, and commit:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-gateway-tls
  namespace: production
spec:
  # The secret name where cert-manager will store the TLS key pair
  secretName: api-gateway-tls-secret
  # Aligns with upcoming 90-day validity standards
  duration: 2160h # 90 days
  renewBefore: 360h # 15 days
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: letsencrypt-production
    kind: ClusterIssuer
  dnsNames:
    - api.production-environment.com

When ArgoCD deploys this manifest, cert-manager detects the new resource, automatically communicates with the ACME server (e.g., Let's Encrypt), solves the DNS-01 or HTTP-01 challenge, and mounts the resulting TLS certificate directly into the application pod as a Kubernetes Secret. The CI/CD pipeline never handles the private key, significantly reducing the risk of exposure.

The Necessity of Independent Expiration Tracking

While automating certificate issuance via cert-manager and GitOps eliminates manual provisioning errors, automation itself can fail. ACME rate limits, misconfigured DNS provider credentials, or network egress issues can silently block renewals.

Because the CI/CD pipeline only deploys the intent to create a certificate (the CRD), a successful pipeline run does not guarantee a successfully issued or renewed certificate. This creates a dangerous blind spot.

To mitigate this, infrastructure teams must implement independent monitoring that verifies the actual cryptographic state of the deployed endpoints. Services like Expiring.at provide this critical safety net. By monitoring the live endpoints externally, you ensure that even if your automated CI/CD deployment or in-cluster ACME client fails silently, you receive actionable alerts well before a certificate expires and causes an outage.

Securing the Software Supply Chain with Keyless Code Signing

CI/CD pipelines deal with two distinct categories of certificates: TLS certificates used to secure the deployed infrastructure, and code-signing certificates used to verify the integrity of the software artifacts (container images, binaries, SBOMs) produced by the pipeline.

Supply chain attacks, such as the SolarWinds breach, often involve attackers compromising a build environment to steal long-lived code-signing certificates. With these stolen certificates, attackers can sign malicious artifacts, tricking downstream systems into trusting compromised code.

To comply with modern security frameworks like Supply-chain Levels for Software Artifacts (SLSA), organizations are abandoning static code-signing keys in favor of "keyless" signing architectures.

Implementing Sigstore and Fulcio

Sigstore, specifically its Fulcio component, has revolutionized how CI/CD pipelines sign artifacts. Fulcio is a free root certificate authority that issues short-lived, ephemeral certificates based on an OIDC identity.

Instead of managing a GPG key or an RSA private key in your CI variables, the pipeline uses its OIDC token (the same mechanism used to solve the Secret Zero problem) to request an ephemeral certificate from Fulcio. The pipeline signs the container image, publishes the signature and the public key to a tamper-resistant transparency log (Rekor), and then discards the private key.

Because the certificate is only valid for a few minutes—just long enough to complete the build job—it is completely useless to an attacker who compromises the pipeline later.

Here is how you implement keyless signing for a Docker image using the Cosign CLI in a GitHub Actions workflow:

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write # Required for keyless signing via OIDC

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3
        with:
          cosign-release: 'v2.2.0'

      - name: Build and Push Container Image
        id: build-and-push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/my-org/my-app:${{ github.sha }}

      - name: Sign the published Docker image
        env:
          # Enable keyless signing
          COSIGN_EXPERIMENTAL: "true"
        run: |
          cosign sign --yes \
            ghcr.io/my-org/my-app@${{ steps.build-and-push.outputs.digest }}

Downstream Kubernetes clusters can then use admission controllers (like Kyverno or Sigstore Policy Controller) to verify the signature against the transparency log before allowing the container to run, ensuring cryptographic proof of origin without ever managing a static code-signing certificate.

Architecting for Crypto-Agility and Compliance

The push for automated certificate integration in CI/CD is not just driven by operational efficiency; it is increasingly a strict regulatory requirement.

The Digital Operational Resilience Act (DORA), taking effect in the EU in January 2025, mandates stringent ICT risk management for financial entities. This includes proving the ability to rapidly rotate cryptographic assets without operational disruption. Similarly, PCI-