What this article covers
- What attestation-based admission means in practice
- How Kyverno and In-Toto work together at the admission layer
- The difference between image signing and attestation verification
- Common predicate types and what each proves
- When attestation-based policies fail and what that indicates
The core problem: signatures alone prove nothing useful
Signing a container image proves one thing — that someone with a specific key signed it. It does not prove:
- Where the image was built
- What source code went into it
- Whether security scans passed
- Whether required build steps were executed
Software artifacts are generally opaque blobs that can't easily be inspected for safety, so it's more common to reason about how they came to be rather than what is in them. We can't apply policy to individual lines of code, we apply policy on who built the software, how they built it, and where the code came from. This is the gap attestations fill. An attestation is a signed statement that captures specific metadata about an artifact — its provenance, its dependencies, its scan results.
What is an attestation
A software attestation is an authenticated statement (metadata) about a software artifact or collection of software artifacts. The primary intended use case is to feed into automated policy engines. An attestation has three layers:
Layer
Purpose
Envelope (DSSE)
Carries the signature and provides cryptographic verification
Statement
Binds the attestation to specific artifacts via subject and digest
Predicate
Contains the actual metadata — provenance, SBOM, scan results
The predicate is the metadata associated with the artifact, as a JSON object. The content of this object is derived from the value of the predicateType field. This might include the provenance (description of the origins of the artifact), SBOM (description of the contents and dependencies of the artifact), security checks such as SAST/DAST, and more.
What In-Toto provides
In-toto provides a framework to protect the integrity of the software supply chain. It does so by verifying that each task in the chain is carried out as planned, by authorized personnel only, and that the product is not tampered with in transit. In-Toto defines:
- The attestation format — a standard structure for expressing claims about artifacts
- Predicate types — schemas for specific kinds of evidence (provenance, SBOM, vulnerability scans)
- Verification logic — rules for validating that attestations match expected supply chain steps
The in-toto Attestation Framework defines a fixed, lightweight Statement that communicates some information about the execution of a software supply chain, such as if the source was reviewed, or if it went through a SLSA conformant build process. The information is communicated as a Predicate using a context-specific schema identified by a Predicate Type.
What Kyverno does at admission
Kyverno runs as a dynamic admission controller in a Kubernetes cluster. Kyverno receives validating and mutating admission webhook HTTP callbacks from the Kubernetes API server and applies matching policies to return results that enforce admission policies or reject requests. For image verification specifically, Kyverno:
- Intercepts pod creation requests
- Extracts container image references
- Fetches signatures and attestations from the OCI registry
- Verifies signatures against configured attestors (keys, certificates, or keyless identity)
- Validates attestation predicates against policy conditions
- Admits or rejects the pod based on verification results
The policy rule check fails if the signature is not found in the OCI registry, or if the image was not signed using the specified key. The rule mutates matching images to add the image digest, when mutateDigest is set to true, if the digest is not already specified.
Common predicate types and what they prove
Predicate Type
URI
What It Proves
SLSA Provenance
https://slsa.dev/provenance/v1
Where, when, how the artifact was built; which builder produced it
CycloneDX SBOM
https://cyclonedx.org/bom
Full list of components and dependencies in the artifact
SPDX SBOM
https://spdx.dev/Document
Component inventory in SPDX format
Vulnerability Scan
cosign.sigstore.dev/attestation/vuln/v1
Results of vulnerability scanning, including scan timestamp
In-Toto Link
https://in-toto.io/attestation/link/v0.3
Evidence that a specific supply chain step executed with specific inputs/outputs
The vulnerability predicate can be used to verify the compliance of the artifact against the company Security Gate. The test-result predicate can be used to verify the compliance of the artifact against the company Quality Gate.
How Kyverno verifies In-Toto attestations
A Kyverno policy for attestation verification specifies:
- Image references — which images the policy applies to
- Attestors — who is trusted to sign (public key, certificate, or keyless identity via OIDC)
- Attestations — which predicate types are required
- Conditions — specific values that must be present in the predicate
Example: requiring SLSA provenance from a specific GitHub Actions workflow: attestations:
Signing and attesting are valuable because they enforce guarantees — e.g., that an image hasn't been tampered with or that it includes specific dependencies. To verify these claims at deployment, we use Kyverno, a Kubernetes policy engine that intercepts admission requests.
Two verification approaches: keyed vs keyless
Key-based verification — You manage signing keys. The policy contains the public key or references a Kubernetes secret. Simpler to understand, but requires key distribution and rotation. Keyless verification (Sigstore) — No long-lived keys. Signing happens via OIDC identity (GitHub Actions, Google, etc.) and is recorded in a transparency log (Rekor). The policy specifies trusted issuers and subject patterns. The following policy verifies an image signed using ephemeral keys and signing data stored in a transparency log, known as keyless signing. Keyless is increasingly common for CI/CD-generated attestations because it eliminates key management while providing verifiable identity binding.
What admission failure indicates
When Kyverno rejects a pod due to attestation verification failure, the cause is one of:
Failure
Meaning
Signature not found
Image was never signed, or signature is stored in a different registry
Signature verification failed
Signature exists but doesn't match the configured attestor
Attestation not found
Image is signed but the required predicate type is missing
Attestation condition failed
Attestation exists but predicate values don't match policy
Each failure type points to a different remediation path — missing signatures require pipeline changes, while condition failures may indicate policy misconfiguration or legitimate policy violations.
Notes
- Attestation verification adds latency to pod admission. Kyverno caches verification results to mitigate this.
- The cache is enabled by default and significantly helps with execution time of verify image policies by making not accessing remote repository on every verification attempt.
- Keyless verification requires network access to transparency logs during verification.
- Attestations must be pushed to the same OCI registry as the image (or a configured alternate repository).
Sources:
- Kyverno Documentation: https://kyverno.io/docs/
- In-Toto Specification: https://github.com/in-toto/attestation
- SLSA Framework: https://slsa.dev/
- Sigstore Project: https://sigstore.dev/