Skip to content

OCI Images: KCA practice questions

This topic is about proving where container images come from before they run. An image referenced by tag, such as myapp:1.4.0, can be re-pointed at different content, while a reference by digest, myapp@sha256:..., names exact bytes.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What OCI Images covers in KCA

This topic is about proving where container images come from before they run. An image referenced by tag, such as myapp:1.4.0, can be re-pointed at different content, while a reference by digest, myapp@sha256:..., names exact bytes. The Kyverno documentation spells out the benefit: a digest makes the reference immutable, prevents spoofing, and keeps the deployed image identical to the one that was scanned and verified.

The verifyImages rule checks signatures and attestations. It supports Sigstore Cosign and Notary, and the attestor types depend on the tool; with Cosign an attestor can be a public key, a certificate or a keyless identity. imageReferences lists the image patterns the rule applies to, for example a registry path ending in a wildcard. Each attestor holds entries. A keys entry carries a public key inline or from a Kubernetes Secret. A certificates entry carries a certificate and, or only, a root certificate chain. A keyless entry matches the identity recorded when the image was signed through subject and issuer, or their regular-expression variants, and the documentation stresses that these must match the identity used at signing time. Transparency log settings for Rekor and the certificate transparency log can be adjusted, and ignoreTlog disables the Rekor check. A signature proves who signed which digest; it says nothing about whether the image is free of vulnerabilities.

Attestations are signed statements about an image, such as an SBOM or a scan result. An attestations entry names a predicateType, its own attestors, and conditions that are evaluated against the predicate content. A single verifyImages rule verifies either signatures or attestations, not both, so checking both needs two rules.

Three switches shape the result, all true by default. mutateDigest rewrites a matching image reference to include its digest, so the Pod that is admitted points at exactly what was verified. verifyDigest makes the validation phase require digests for matching images. required makes the validation phase check that each matching image carries an immutable annotation marking it as verified. The rule's failureAction decides whether a failure blocks the request. Verification runs in the mutating webhook after other mutation rules, and again during validation.

Because each verification needs several registry calls, Kyverno caches successful results. Caching is on by default with up to 1000 entries for 60 minutes, set by imageVerifyCacheEnabled, imageVerifyCacheMaxSize and imageVerifyCacheTTLDuration, so a changed signature or image is noticed only after the entry expires. Rules can also read image details through the images variable, which exposes registry, path, name, tag and digest for each container image in the request, or fetch image metadata from the registry with an imageRegistry context entry.

In Kyverno 1.19 the legacy verifyImages rule belongs to the deprecated ClusterPolicy kind; ImageValidatingPolicy is its CEL-based replacement in policies.kyverno.io.

Key points

  • A verifyImages rule checks either signatures or attestations, never both in one rule.
  • mutateDigest, verifyDigest and required all default to true.
  • Keyless attestors must match the subject and issuer recorded at signing.
  • Successful verifications are cached for 60 minutes by default.

Three sample questions

8 KCA questions on OCI Images, 8 with explanations. How practice works

Question 1

A colleague argues that myapp:1.4.0 and myapp@sha256:3f29b8... are just two different ways of writing "the same reference." Why is this claim wrong?
  1. A.They are exactly the same; the claim is correct.
  2. B.Digest references are slower to resolve than tag references, but otherwise identical.
  3. C.Tags only work with Docker Hub; digests only work with private registries.
  4. D.A tag is a mutable pointer a registry can repoint to a different manifest at any time; a digest names one specific, immutable manifest forever.

Correct answer: D

A tag is a label the registry stores as a pointer to whatever manifest digest was most recently pushed under that name — it can be repointed. A digest reference names the manifest by its own content hash, so it can only ever resolve to one exact set of bytes.

Question 2

You want to know exactly what image bytes a running Pod actually pulled, independent of whatever tag was written in its spec. Which field do you check?
  1. A..spec.containers[0].image
  2. B..metadata.annotations.image
  3. C..status.containerStatuses[0].imageID
  4. D..status.containerStatuses[0].image

Correct answer: C

imageID is the only field that reports the digest the kubelet actually resolved and pulled. Both the spec and the status image fields simply echo whatever reference string (tag or digest) was written in the Pod spec.

Question 3

What does a valid Cosign signature on an image digest actually prove?
  1. A.That the holder of a specific key (or verified identity) vouched for that exact digest.
  2. B.That the image contains no known vulnerabilities.
  3. C.That the image was built by an approved CI pipeline.
  4. D.That the image has never been pulled by an unauthorized user.

Correct answer: A

A signature is narrow and specific: it proves who (which key or identity) vouched for a specific digest. It says nothing on its own about vulnerability status or build process.

Practice this topic

Focus mode keeps every question on OCI Images until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

Does a valid Cosign signature mean an image is safe to run?

No. It shows that a trusted key or identity signed that exact digest, which establishes origin and integrity. Vulnerability or SBOM requirements are checked separately with attestations and conditions.