Understanding Tekton Chains
Tekton Chains is a powerful security component within the Tekton ecosystem that helps secure your software supply chain by generating, signing, and storing provenance for artifacts built with Tekton Pipelines. This document provides an in-depth explanation of how Tekton Chains works and its key components.
Terminology
Term | Description |
---|
Provenance | Metadata that describes how an artifact was produced, including the build process, inputs, and environment |
SLSA | Supply-chain Levels for Software Artifacts - a security framework for software supply chain integrity |
Attestation | Authenticated metadata about software artifacts, following the in-toto attestation format |
Signature | Cryptographic proof that verifies the authenticity and integrity of provenance data |
Type Hinting | Specially named results/params that help Tekton Chains understand inputs and outputs |
Storage Backend | System where Tekton Chains stores provenance and signatures |
Why Tekton Chains is Needed
The Software Supply Chain Security Challenge
In traditional software development and delivery pipelines, ensuring the integrity and security of artifacts throughout the supply chain presents significant challenges:
- Lack of Traceability: Without proper provenance information, it's difficult to verify where artifacts came from and how they were built
- Tampering Risks: Artifacts can be modified at various stages without detection
- Verification Difficulties: Consumers of artifacts have no reliable way to verify their authenticity
- Compliance Challenges: Organizations struggle to meet increasing regulatory requirements for software supply chain security
These challenges have led to high-profile supply chain attacks like SolarWinds, where malicious code was inserted into the build process, affecting thousands of organizations.
Tekton Chains' Solution
Tekton Chains addresses these challenges by:
- Automatic Provenance Generation: Capturing detailed metadata about the build process
- Cryptographic Signing: Ensuring the integrity and authenticity of provenance data
- Standardized Formats: Supporting industry-standard formats like SLSA provenance
- Flexible Storage: Providing multiple options for storing and retrieving provenance
- Integration with Existing Tools: Working with tools like Sigstore, Cosign, and cloud KMS services
By implementing Tekton Chains, organizations can achieve higher levels of supply chain security and meet SLSA compliance requirements.
Advantages
- Automation: Automatically generates and signs provenance without manual intervention
- Standardization: Supports industry-standard formats like SLSA and in-toto
- Flexibility: Works with various signing mechanisms and storage backends
- Integration: Seamlessly integrates with the Tekton Pipelines ecosystem
- Transparency: Provides clear visibility into how artifacts were produced
- Compliance: Helps meet regulatory and industry requirements for supply chain security
Scenarios
Scenario 1: Securing Container Image Builds
A development team uses Tekton Pipelines to build container images. By implementing Tekton Chains, they can automatically generate signed provenance for each image, which includes details about the source code, build environment, and build steps. This provenance is stored alongside the image in their container registry, allowing downstream consumers to verify the image's authenticity and build process.
Scenario 2: Compliance with Security Requirements
An organization needs to comply with security requirements that mandate traceability and integrity verification for all deployed software. By using Tekton Chains, they can generate SLSA provenance for all artifacts, providing cryptographic proof of how each artifact was built and from what sources. This helps them meet audit requirements and demonstrate due diligence in securing their supply chain.
Scenario 3: Detecting Supply Chain Attacks
A security team wants to ensure that no unauthorized changes occur in their build process. With Tekton Chains, any attempt to tamper with the build process would result in provenance that doesn't match the expected values. By implementing verification steps in their deployment process, they can automatically detect and prevent the deployment of artifacts with suspicious provenance.
Constraints and Limitations
- Kubernetes Dependency: Requires a Kubernetes cluster with Tekton Pipelines installed
- Configuration Complexity: Proper type hinting configuration is required for accurate provenance
- Key Management: Secure management of signing keys is essential
- Storage Requirements: Additional storage is needed for provenance and signatures
- Performance Impact: Signing and storing provenance adds some overhead to the build process
Principles
How Tekton Chains Works
Tekton Chains operates through a controller that observes TaskRun and PipelineRun resources in a Kubernetes cluster. The workflow follows these steps:
- Observation: The controller watches for completed TaskRuns and PipelineRuns
- Snapshot: When a run completes, Chains takes a snapshot of its state
- Formatting: Chains generates provenance in the configured format (e.g., SLSA)
- Signing: The provenance is cryptographically signed using the configured method
- Storage: Both the provenance and signature are stored in the configured backends

Provenance Generation
Tekton Chains uses type hinting to understand the inputs and outputs of a build process. This information is then used to generate provenance in the specified format:
- Input Collection: Chains identifies input artifacts through type hints
- Build Process Capture: Details about the build environment and steps are recorded
- Output Identification: Output artifacts are identified through type hints
- Provenance Assembly: All information is assembled into a standardized format
Signing Process
Tekton Chains supports multiple signing methods to accommodate different security requirements:
- Key Retrieval: The signing key is retrieved from the configured source
- Payload Preparation: The provenance data is prepared for signing
- Signature Generation: A cryptographic signature is generated
- Verification Data: Additional data needed for verification is included
Configuration Examples
Basic SLSA v1.0 Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: chains-config
namespace: tekton-chains
data:
artifacts.taskrun.format: "slsa/v2alpha3"
artifacts.taskrun.storage: "tekton,oci"
artifacts.taskrun.signer: "x509"
artifacts.pipelinerun.format: "slsa/v2alpha3"
artifacts.pipelinerun.storage: "tekton"
artifacts.pipelinerun.signer: "x509"
artifacts.oci.format: "simplesigning"
artifacts.oci.storage: "oci"
artifacts.oci.signer: "x509"
Type Hinting Example for Git Source
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: build-from-source
spec:
taskSpec:
results:
- name: CHAINS-GIT_URL
description: The Git repository URL
- name: CHAINS-GIT_COMMIT
description: The Git commit SHA
- name: IMAGE_URL
description: The URL of the built image
- name: IMAGE_DIGEST
description: The digest of the built image
steps:
# Task implementation
Important Parameters
Storage Configuration
Storage backends determine where provenance and signatures are stored. This is crucial for ensuring that provenance is accessible when needed for verification.
Use Cases
- Tekton Storage: Useful for debugging and internal verification
- OCI Storage: Ideal for storing provenance alongside container images
- GCS/DocDB Storage: Suitable for centralized storage and management
Configuration Example
artifacts.taskrun.storage: "tekton,oci"
artifacts.pipelinerun.storage: "tekton"
artifacts.oci.storage: "oci"
Signing Configuration
The signing configuration determines how provenance is cryptographically signed, which is essential for verifying its authenticity.
Use Cases
- x509: Standard certificate-based signing
- KMS: Cloud-based key management for enhanced security
- Keyless: Zero-trust signing with ephemeral keys
Configuration Example
artifacts.taskrun.signer: "x509"
artifacts.pipelinerun.signer: "x509"
artifacts.oci.signer: "x509"
References