No artifact identity — relying on tags instead of digests

An artifact without identity is an artifact whose bytes the team cannot name. The deployment manifest says myorg/api:v3; the cluster pulls whatever the registry serves for myorg/api:v3; the deployment is consistent with the manifest, but the bytes under that tag are not the bytes the team reviewed. Six hours later, somebody re-tags the image; the deployment is now consistent with the manifest and a different artifact.

Four shapes the violation takes

• Image references by tag. A Kubernetes Deployment with image: myorg/api:v3. The v3 is a pointer; the registry decides what it points at.
• Helm values with tag: latest. A values file that names a tag rather than a digest.
• OCI artifact references by tag in CI. A pipeline publishes myorg/api:v3 and a downstream pipeline pulls the same tag; both reference the label, neither references the bytes.
• Terraform module references by tag. A source = "...?ref=v1.2.0" in a module block; the tag is mutable; the bytes are mutable.

    flowchart LR
        A["image: myorg/api:v3"] --> E["Resolves at pull time"]
        B["Helm tag: latest"] --> E
        C["OCI tag in CI"] --> E
        D["TF ref=v1.2.0"] --> E
        E --> F["Bytes the team did not review"]
        F --> G["Audit trail has no digest"]
        F --> H["Re-tag silently changes production"]

All four converge: the bytes that run in production are not the bytes the build produced.

Why a tag is not identity

A tag is a label the publisher assigns. The publisher controls which bytes receive the label, when the label is moved, and how long the label persists. Three moves the publisher can make: move - push a new image and re-tag v3 to point at it; re-push - delete and re-push the same tag with different bytes; yank - mark the image as not-for-new-pulls; existing deployments keep running the old bytes; new deployments fail.

A digest is a content-addressed identifier. The publisher cannot move the digest to different bytes because the digest is a function of the bytes. sha256:... names exactly the image whose hash it is.

What digest pinning looks like

• image: myorg/api@sha256:... in Kubernetes manifests. The tag is a comment for humans; the digest is what the scheduler resolves.
• helm install --set image.digest=sha256:... for chart-driven deployments.
• oci://registry/myorg/api@sha256:... in CI pipelines.
• Vendored Terraform modules at a digest-named directory or with a commit SHA pinned in source.

Production discipline

1. Every artifact reference is by digest. Tags appear in comments and changelogs; digests appear in manifests, charts, and CI pipelines.
2. The GitOps repository names the digest, not the tag.
3. The CI pipeline emits a signed attestation that binds the artifact to the digest.
4. Re-tagging is a CI failure, not a routine operation.

Cross-course references

• This course, Part XLV (ArtifactImmutability) - immutable-identity principle and digest pinning in depth.
• This course, Part XLIV (ArtifactStorage) - retention and registry configuration that supports digest-pinned pulls.
• Linux for Production Sysadmins, Part XIII (PkgMgmt) - apt/dnf digest verification.

Quiz