Next-gen supply chain security with HashiCorp Vault and Tekton Chains

You can also read this article on our Substack!

Why supply chain security matters

In the world of cloud-native development, your speed and complexity have outpaced traditional security models. The high-profile supply chain attacks of recent years have shown that the vulnerability often lies not in the final application, but in the process of building it: the software supply chain.

To defend against tampering, you need two things: Provenance (a verifiable record of how an artifact was built) and Integrity (cryptographic proof that the artifact hasn’t been changed since it was built). This is where key technologies — Tekton, the Kubernetes-native CI/CD engine, and HashiCorp Vault, the secrets and encryption management platform — come together to establish a chain of trust.

This post explores the concepts that secure the modern pipeline and shows how integrating HashiCorp Vault as a Key Management Service (KMS) with Tekton Chains provides a robust, identity-driven approach to digital signing.

The benefits of a secure supply chain

A secure software supply chain moves beyond scanning code for vulnerabilities. It focuses on confirming that every artifact (code, container image, manifest) is built in a trusted environment and has verifiable, tamper-proof metadata attached.

The core benefits of adopting strong supply chain concepts include:

1. Cryptographic integrity and non-repudiation

By signing every task and final artifact (like a container image), you create a digital ledger. This ensures that a consumer can verify two things:

• The artifact they are running has not been tampered with since it was built.
• The artifact was built by a trusted identity (the CI/CD system) that possesses the private signing key.

2. SLSA provenance

Tekton Chains automatically generates Supply-chain Levels for Software Artifacts (SLSA) compliant provenance metadata. SLSA provides a standardized, machine-readable record detailing when, where, and how an artifact was produced, adding a critical layer of auditable trust.

3. Policy enforcement

You can enforce security gates, with signed artifacts, by configuring tools such as Open Policy Agent (OPA) and Kyverno to only allow deployments that are checked against a known and trusted public key. This guarantees that only authorized and verified builds can get to production.

Tekton Chains meets HashiCorp Vault

The integration of a CI/CD platform and a dedicated secrets manager is the most critical step in securing the supply chain.

The Tekton side: automated signing

**Tekton Pipelines provides a Kubernetes-native, declarative way to define CI/CD workflows. The key component for supply chain security comes from [Tekton Chains](https://tekton.dev/docs/chains/)**, an add-on that automatically:

1. Observes every TaskRun and PipelineRun.
2. Gathers provenance data (who, what, where).
3. Signs the provenance and the resulting artifact (e.g., a container image).
4. Stores the signature and provenance in a registry or log.

OpenShift Pipelines uses Tekton Chains for supply chain security, as its CI/CD core is purely Tekton.

The Vault side: the trusted key manager

While Tekton Chains handles the process of signing, **HashiCorp Vault provides the vital component: the signing key**. Storing the private key directly in a Kubernetes secret is a risk. Vault, however, improves security with:

• Centralized key management: Tekton Chains uses Vault transit secrets engine as a Key Management Service (KMS). The private signing key never needs to leave the Vault security boundary, making the process one of “signing as a service.” For organizations bound by CAB Forum requirements or federal mandates, Vault Enterprise extends this capability to Hardware Security Modules (HSMs). This allows you to use HSM-backed keys within the transit engine, ensuring your supply chain meets FIPS 140–2 Level 3 (or higher) standards for cryptographic hardware protection.
• Identity-driven access: Instead of using static tokens, Tekton Chains authenticate to Vault using the JWT auth method. Tekton’s Service Account presents its JWT to Vault, which validates it and grants a short-lived token and access only to the specific key required for signing.

While the standard Vault transit engine can store keys in Vault’s internal encrypted barrier, Vault Enterprise managed keys allow Vault to delegate cryptographic operations to an external HSM or Cloud KMS.

This architecture with ephemeral identities creates a stronger and auditable security model.

Secure credentials injection: secrets for the build

Beyond the signing process, a secure CI/CD pipeline also needs access to credentials during the build (e.g., Git credentials, Docker registry credentials). Using static Kubernetes Secrets for this use case is a security liability.

Use HashiCorp Vault to solve this, not only for signing, but also for runtime secrets, showcasing a unified security model.

1. Advanced secrets injection: Vault Secrets Operator with CSI

Vault Secrets Operator with CSI Secrets Driver uses a secure and zero-persistence approach for injecting runtime credentials. This method allows the secrets needed by the pipeline’s tasks to be retrieved from Vault and mounted as a volume directly into the Tekton Pod’s runtime environment.

• Zero persistence: The secrets are never persisted as static Kubernetes Secret objects, significantly reducing the attack surface for Kubernetes administrators or compromised accounts.
• Dynamic access: The CSI driver ensures that the secrets are fetched on demand and are only available for the lifetime of the Tekton task using the pod’s service account identity.

2. The benefit of centralized Vault usage

Using the same Vault instance for both the KMS signing key (for Tekton Chains) and the runtime secrets (via CSI) provides the following security and operational advantages:

• Centralized audit
• Every critical action (key rotation, artifact signing, secret access) is logged and audited by a single, authoritative source (Vault).
• Consistent policy
• Access control policies (e.g., who can sign artifacts, who can retrieve Git credentials) are defined and enforced using one identity model (Vault’s Kubernetes Auth Method), reducing configuration drift.
• Simplified operations
• Managing a single, highly available Vault cluster is simpler than managing separate signing services and secrets stores.

By using Vault for both key management and credential injection, you ensure the integrity of your pipeline (through signing) and the security of your build environment (through ephemeral secrets), all governed by a single, trusted security boundary.

Verifying the chain of trust

Once a pipeline completes, you can verify the integrity of the image using Cosign and point it directly to the Vault KMS.

Instead of needing a local key file, the verification command resolves the public key directly from Vault, confirming both the image’s integrity and the source of the signing key.

# Verify the image signature using the Vault key
cosign verify --key hashivault://supply-chain [YOUR_DOCKER_IMAGE_URL]

This final step completes the verification chain, proving that the artifact was built by an authorized, secured pipeline using keys managed by your central authority, HashiCorp Vault.

Conclusion

By integrating HashiCorp Vault as the KMS with Tekton Chains, you transform your CI/CD process from a potential security vulnerability into a secure, verifiable, and auditable system. This model prioritizes:

• Zero trust authentication with Kubernetes JWT.
• Centralized key protection with the Vault transit engine.
• Tamper-proof provenance with SLSA standards.

Explore this architecture in action, including the setup for Vault, Tekton, and the secure secrets injection patterns (Vault Secrets Operator with CSI), in the **vault-tekton-chains** repository.