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

TermDescription
ProvenanceMetadata that describes how an artifact was produced, including the build process, inputs, and environment
SLSASupply-chain Levels for Software Artifacts - a security framework for software supply chain integrity
AttestationAuthenticated metadata about software artifacts, following the in-toto attestation format
SignatureCryptographic proof that verifies the authenticity and integrity of provenance data
Type HintingSpecially named results/params that help Tekton Chains understand inputs and outputs
Storage BackendSystem 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:

  1. Automatic Provenance Generation: Capturing detailed metadata about the build process
  2. Cryptographic Signing: Ensuring the integrity and authenticity of provenance data
  3. Standardized Formats: Supporting industry-standard formats like SLSA provenance
  4. Flexible Storage: Providing multiple options for storing and retrieving provenance
  5. 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:

  1. Observation: The controller watches for completed TaskRuns and PipelineRuns
  2. Snapshot: When a run completes, Chains takes a snapshot of its state
  3. Formatting: Chains generates provenance in the configured format (e.g., SLSA)
  4. Signing: The provenance is cryptographically signed using the configured method
  5. Storage: Both the provenance and signature are stored in the configured backends

Tekton Chains Workflow

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:

  1. Input Collection: Chains identifies input artifacts through type hints
  2. Build Process Capture: Details about the build environment and steps are recorded
  3. Output Identification: Output artifacts are identified through type hints
  4. Provenance Assembly: All information is assembled into a standardized format

Signing Process

Tekton Chains supports multiple signing methods to accommodate different security requirements:

  1. Key Retrieval: The signing key is retrieved from the configured source
  2. Payload Preparation: The provenance data is prepared for signing
  3. Signature Generation: A cryptographic signature is generated
  4. 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