How do you make sure only trusted container images can run in your cluster, and what does signing an image actually prove?

technical-conceptual · Mid level · cloud-devops-security

What the interviewer is really asking

Test understanding of container supply-chain security beyond vulnerability scanning — image provenance, signing, and admission-time enforcement, and the limits of what a signature guarantees.

What to say

• Separate the two halves: signing establishes provenance and integrity (this image came from a build you trust and hasn't been tampered with since), and admission control enforces that only signed-and-verified images are allowed to run. A signature does NOT mean the image is vulnerability-free — you still need scanning; it means you know who produced it and that the digest is unaltered.
• Describe the modern keyless flow with cosign: instead of a long-lived signing key, the CI job authenticates via OIDC, Fulcio issues a short-lived certificate bound to that workload identity, the signature and an in-toto/SLSA provenance attestation (and often an SBOM) are pushed to the registry, and the event is logged in the Rekor transparency log so it's publicly auditable. Always pin and verify by immutable digest (sha256:...), never a mutable tag.
• Enforce it at the gate: an admission controller like Kyverno or the sigstore policy-controller verifies the signature and checks the signer identity (the expected CI OIDC issuer/subject) before the pod is admitted, so an unsigned or wrongly-signed image is rejected at deploy time rather than discovered later. Tie it back to a framework like SLSA to show you understand build-provenance levels.

What to avoid

• Saying a signed image is 'secure' or 'safe to run' — signing proves origin and integrity, not the absence of CVEs or malware in the source.
• Stopping at 'we scan images with Trivy' as the whole answer; scanning finds known vulnerabilities but does nothing to prove the image is the one your pipeline actually built.
• Relying on mutable tags like :latest for verification, or treating storing keys in a CI variable as equivalent to keyless/identity-based signing with a transparency log.

Example answers

Strong: In our GitHub Actions pipeline the build step uses cosign keyless signing: the job's OIDC token gets a short-lived Fulcio cert, we sign the image by digest and attach an SBOM and SLSA provenance attestation, all recorded in Rekor. In the cluster, a Kyverno policy verifies the signature against our expected OIDC subject (the repo's workflow identity) and blocks any image that isn't signed by it — so even if someone pushed a malicious image to the registry, it can't be admitted because it wasn't signed by our pipeline identity.

Weak: We trust our images because we scan them with Trivy and there are no critical vulnerabilities.