Artifact Repository and Image Security: KCSA practice questions

Artifact repository and image security is about trusting the code a cluster runs. An image is built, pushed to a registry, pulled onto a node and started by the container runtime, and an attacker who can tamper with any of those steps can run code inside your workloads. The defenses fall into three groups: keep the image itself small and patched, make the reference to it immutable, and verify where it came from before it is admitted.

Image content comes first. The Kubernetes security checklist asks you to minimize unnecessary content in container images, to configure images to run as an unprivileged user, and to scan images regularly both when they are created and while they are deployed, patching known vulnerable software. A multistage build serves the first goal: compilers, package managers and test tooling stay in an earlier build stage, and only the runtime artifacts are copied into the final stage, so there is less software for a scanner to flag and for an attacker to use. When a scanner reports a vulnerable image, the fix is to rebuild from a patched base and redeploy, not to retag the same content.

References matter as much as content. Kubernetes documentation states that tags can be moved to point to different images while digests are fixed, because a digest is a hash of the image content. A reference such as image@sha256:... pins the exact bytes you run; when an image reference carries both a tag and a digest, only the digest is used for pulling. The same documentation advises against the latest tag in production, because it is harder to track which version is running and harder to roll back. If no tag is given at all, Kubernetes assumes latest.

The pull policy controls when the kubelet goes back to the registry. With IfNotPresent the image is pulled only if it is not already on the node, with Always the runtime resolves the tag to a digest on every container start, and with Never the kubelet does not try to fetch the image, so startup fails if it is not present locally. Private registries are reached with imagePullSecrets, which must be Secrets of type kubernetes.io/dockercfg or kubernetes.io/dockerconfigjson in the same namespace as the Pod. In multi-tenant clusters the AlwaysPullImages admission controller matters: without it, a Pod can start from an image already cached on the node even if its owner holds no credentials for that registry.

Provenance closes the loop. Sigstore signs artifacts with cosign, issues short-lived certificates bound to an OIDC identity through Fulcio, and records the signature in the Rekor transparency log, so a successful verification shows that the image is unaltered and came from the expected identity. Kubernetes signs its own release images this way. To make verification mandatory, the security checklist asks that image provenance is validated at deploy time through admission control, for example with the sigstore policy-controller or a policy engine; a registry list alone does not prove who built the image.