Content Trust

Content trust relies on asymmetric cryptography where publishers sign images with a private key and consumers verify with a public key. The Notary project implements The Update Framework (TUF) to manage this trust hierarchy.

• Signing Process: A publisher hashes the image manifest and encrypts the hash with their private key
• Verification: The runtime decrypts the signature using the trusted public key and compares hashes
• Key Management: TUF separates root, targets, snapshot, and timestamp keys with offline root keys for maximum security

This prevents man-in-the-middle attacks and ensures the image pulled is bit-for-bit identical to what the publisher signed.

TUF provides a robust key hierarchy designed to survive key compromise. It separates roles so that compromising a single online key cannot poison the entire repository.

• Root Key: Stored offline; signs the trusted root metadata
• Targets Key: Signs image manifests and delegations
• Snapshot Key: Signs metadata about the latest collection of files to prevent rollback attacks
• Timestamp Key: Signs short-lived metadata to ensure freshness and prevent freeze attacks

TUF also supports threshold signatures, requiring multiple keys to sign critical metadata, eliminating single points of failure.

Notary v2 is the modern evolution of content trust, natively integrated with the OCI Distribution Specification. Unlike Notary v1, it stores signatures as OCI Artifacts alongside images in the same registry.

• Signature Format: Uses JSON Web Signatures (JWS) for portability
• Referrers API: Allows discovery of all signatures and attestations for a given image digest
• Multi-Signature Support: Multiple parties can independently sign the same image

This architecture eliminates the need for a separate Notary server, reducing operational complexity while maintaining cryptographic guarantees.

Cosign, part of the Sigstore project, enables keyless signing using OpenID Connect identities. Developers authenticate via their email or workload identity, and a short-lived certificate is issued.

• Fulcio: A certificate authority that issues ephemeral signing certificates bound to OIDC identities
• Rekor: A transparency log that records signatures, making them auditable and discoverable
• Verification: Consumers verify the certificate chain and check the Rekor log entry

This eliminates the operational burden of managing long-lived signing keys while providing a tamper-evident audit trail.

Content trust is enforced at deploy time through Kubernetes Admission Controllers. These webhooks intercept pod creation requests and validate image signatures before the pod is persisted.

• Gatekeeper/OPA: Policy engines that reject pods with unsigned or invalidly signed images
• Kyverno: A Kubernetes-native policy engine that can verify Cosign signatures natively
• Binary Authorization: GCP's deploy-time control that integrates with attestations

Without enforcement, content trust is advisory. Admission controllers make it mandatory, creating a hard gate that prevents untrusted images from ever reaching the runtime.

Content trust is a foundational component of SLSA Level 2+ compliance. SLSA requires provenance attestations that are cryptographically signed and verifiable.

• SLSA Provenance: A signed document describing how an artifact was built, including builder identity, source repository, and build steps
• Attestation Storage: Provenance documents are stored as OCI artifacts alongside the image
• Policy Verification: Admission controllers verify both the image signature AND the SLSA provenance before allowing deployment

This closes the loop from source code to running container, ensuring the entire software supply chain is verifiable.

A unique, content-addressable SHA256 hash that immutably identifies a specific container image manifest or layer. Unlike mutable tags (latest, v1.0), a digest provides cryptographic verification of integrity—any change to the image produces a completely different hash. Content trust systems pin deployments to digests rather than tags, ensuring that the image pulled at deploy time is byte-for-byte identical to the image that was signed and scanned during the build pipeline. This eliminates TOCTOU (time-of-check-to-time-of-use) attacks where a tag is retargeted to a malicious image.