Supply Chain Security →hardMultiple Choice

CKS Supply Chain Security Practice Question

Exhibit

Refer to the exhibit.

apiVersion: cosigned.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: image-policy
spec:
  images:
  - glob: registry.example.com/*
  authorities:
  - keyless:
      identities:
      - issuer: https://accounts.example.com
        subject: https://github.com/example/actions/.github/workflows/release.yml@refs/heads/main

Refer to the exhibit. A cluster has the ClusterImagePolicy shown. A developer creates a pod with an image from registry.example.com/myapp:v1, which was built and signed by a GitHub Actions workflow that is NOT defined in the policy (different workflow). Which behavior will occur when the pod is created?

⚠ Common exam trap

CNCF often tests the misconception that keyless signing only verifies the signature's cryptographic validity, not the identity of the signer, but in reality the policy enforces identity matching via OIDC claims.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The pod is denied because the image's signer identity does not match the policy.

The ClusterImagePolicy enforces that images must be signed by a specific identity (the GitHub Actions workflow defined in the policy). The image from registry.example.com/myapp:v1 was signed by a different workflow, so the signer identity does not match the policy's required identity. Sigstore keyless signing verifies the OIDC identity embedded in the signature, and if the identity does not match the policy's `issuer` and `subject` patterns, the admission controller denies the pod.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The pod is admitted because keyless signing does not enforce identity matching.
Why it's wrong here
Keyless signing does enforce identity matching: in a ClusterImagePolicy, the `spec.authorities[].identities` field lists expected Fulcio issuer and subject values. The policy evaluator compares the signer's certificate identity against that list, and a mismatch triggers denial rather than admission. Therefore the assertion that keyless signing ignores identity is factually incorrect.
✗
The pod is admitted because the policy only applies to images with a tag 'v*'.
Why it's wrong here
The policy's image glob is `registry.example.com/*`, and the glob wildcard `*` matches any suffix after the slash, including every tag, digest, and even untagged images. This means the policy is not restricted to tags beginning with 'v'; it applies to all images under the allowed registry path. Since the pod's image falls into that matched pattern, the tag-based exemption claim is false.
✗
The pod is admitted because the image is from the allowed registry.
Why it's wrong here
Matching the allowed registry only satisfies the image-name portion of the policy; the ClusterImagePolicy also requires the signature's identity to match an entry in `spec.authorities[].identities`. An image from registry.example.com is still rejected if its signer's Fulcio issuer or subject is not present in that list. Registry allow-listing is necessary but not sufficient for admission.
✓
The pod is denied because the image's signer identity does not match the policy.
Why this is correct
Cosigned's admission webhook evaluates both the image reference and the signature's identity. Because the keyless certificate presented for this image has an issuer or subject that does not appear in the policy's `identities` array, the admission request is denied. This is the expected behavior when identity matching is enforced, so the pod cannot be admitted.

Go deeper

CKS Supply Chain Security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question