Alauda DevOps Pipelines Docs

Core Concepts

TOC

Supply Chain Security

Supply chain security refers to protecting the integrity, security, and reliability of the software development lifecycle from development to deployment. Tekton Chains is designed to address supply chain security concerns by providing mechanisms to verify that artifacts produced by CI/CD pipelines have not been tampered with and can be trusted.

SLSA Framework

SLSA (Supply-chain Levels for Software Artifacts) is a security framework that provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. Tekton Chains supports multiple SLSA provenance formats:

  • SLSA v0.2: Supported via slsa/v1 or in-toto formatters
  • SLSA v1.0: Supported via slsa/v2alpha3 and slsa/v2alpha4 formatters

As part of the framework, SLSA has multiple levels of assurances. These levels contain industry-recognized best practices to create four levels of increasing assurance.

Security levels

Track/LevelRequirementsFocus
Build L0(none)(n/a)
Build L1Provenance showing how the package was builtMistakes, documentation
Build L2Signed provenance, generated by a hosted build platformTampering after the build
Build L3Hardened build platformTampering during the build

Tekton can achieve SLSA Level 2 compliance. For more information, please refer to Getting To SLSA Level 2 with Tekton and Tekton Chains

Signing

Signing is the process of cryptographically signing provenance to ensure its integrity and authenticity. Tekton Chains supports multiple signing methods:

  • x509: Uses a standard x509 certificate and private key
  • Cosign: Uses Sigstore's Cosign tool for signing
  • KMS: Uses cloud provider key management services
  • Keyless: Uses ephemeral keys with Fulcio certificate authority

Image attestation

Image attestation is used for storing and verifying metadata information related to images. It provides richer supply chain security information, such as:

SLSA Provenance

SLSA Provenance is metadata containing verifiable information about software artifacts, describing how they were built, what sources were used, and who built them. In Tekton Chains, provenance is cryptographically signed to ensure its integrity and authenticity.

There are two types of provenance in Tekton Chains:

  • Task-level provenance: Captures details about a specific TaskRun execution
  • Pipeline-level provenance: Captures the entire PipelineRun execution, including all child TaskRuns

SBOM (Software bill of materials)

SBOM is a nested inventory for software, a list of ingredients that make up software components, including:

  • Software components
  • Component versions
  • License information
  • Dependency relationships

SBOM can be in various formats, such as:

Vulnerability scan results

Cosign Vulnerability Scan results record the security assessment of the software build process, including:

  • Scanner information (name, version)
    • Vulnerability database information
  • List of discovered vulnerabilities and their severity
  • Remediation recommendations

Custom metadata

Custom metadata can be added as needed to support specific security requirements.

For example, grype can generate vulnerability scan results, and these results can be uploaded to the image registry as a custom type.

Attestation verification

The verification mechanism is highly flexible and can be customized to validate any metadata present in the attestation. This means that any information stored in the attestation can be used as validation criteria, allowing organizations to implement precise security controls based on their specific requirements.

The flexibility of attestation verification is demonstrated through various validation methods:

  • Kyverno JMESPath Validation

    • Uses JMESPath syntax for JSON query and validation

  • Rego Policy Validation

    • Leverages Open Policy Agent (OPA) for complex policy enforcement
    • Supports declarative policy rules and custom validation logic
    • Example: Validating builder information and build environment

  • CUE Validation

    • Provides type system and constraint system for validation
    • Enables schema validation and data consistency checks
    • Supports complex data structure validation

Artifacts

Artifacts in Tekton Chains refer to the inputs and outputs of a build process:

  • Input Artifacts: Resources that influence the build process, such as source code repositories and dependencies
  • Output Artifacts: Resources produced by the build process, such as container images

Type Hinting

Type hinting is a mechanism used by Tekton Chains to understand the input and output artifacts of a TaskRun or PipelineRun. Type hints are specially named parameters or results that follow specific formats:

  • For Git inputs: CHAINS-GIT_URL and CHAINS-GIT_COMMIT
  • For generic inputs: Parameters or results with the suffix ARTIFACT_INPUTS
  • For image outputs: IMAGES or parameters/results with the suffix IMAGE_URL and IMAGE_DIGEST
  • For generic outputs: Parameters or results with the suffix ARTIFACT_OUTPUTS

Storage Backends

Storage backends are where Tekton Chains stores the generated provenance and signatures. Supported backends include:

  • Tekton: Stores as annotations on the TaskRun/PipelineRun
  • OCI: Stores in an OCI registry alongside container images
  • GCS: Stores in Google Cloud Storage
  • DocDB: Stores in a document database
  • Grafeas: Stores in Grafeas/Container Analysis

Controller

The Tekton Chains controller is the core component that observes TaskRun and PipelineRun executions, captures relevant information, and generates, signs, and stores provenance. It runs as a Kubernetes deployment in the tekton-pipelines namespace.