Registry security

Push control, immutable tags, trust the digest.

The registry sits between build and deploy, holding every artifact your cluster trusts. Hardening it — controlling who can push, making tags immutable, and keeping trust anchored to digests — closes the gap between a verified build and a verified deploy.

Access control and immutability

Treat the registry as a high-value system: tightly scope who and what can push (ideally only your CI pipeline’s identity), so an attacker cannot simply upload a malicious image under a trusted name. Enable tag immutability so a published tag cannot be silently overwritten with different content — a common way tampering slips past teams that pin to tags. Run a private registry for internal artifacts rather than depending on a public one you do not control, and apply the same signature and scan gates on pull that you apply at admission.

# Registry hardening (conceptual):
#  - push:  only the CI OIDC identity has write; humans cannot push to prod repos
#  - tags:  immutable — a published tag cannot be overwritten
#  - pull:  workloads reference images by DIGEST, not by tag
 
# Deploy manifests reference the immutable digest, not a mutable tag:
image: registry.acme.internal/api@sha256:9f2c...   # not :latest
# Combined with admission verification, only the exact verified bytes ever run.

Anchor trust in digests, not names

A registry name and tag are convenience labels, not trust signals — the same tag can point to different content over time, and names can be typosquatted or confused. Anchor everything in the immutable digest: sign by digest, attest by digest, deploy by digest, and verify by digest. Mirror or vendor critical external base images into your controlled registry so an upstream change or deletion cannot break or subvert your builds, and re-scan what you store as new vulnerabilities emerge. The registry becomes a controlled, auditable trust boundary rather than a pass-through.