- Use tags to discover releases, but pin the production reference to a digest.
- Verify the publisher and signature before approval; a digest proves identity, not safety.
- Let automation propose new digests through review instead of letting a reused tag change live code.
A container tag looks like a version. It is really a pointer, and the registry owner can move it to different content.
That is convenient during development. In production, it can leave two replicas of one service running different bytes after a restart. The manifest still says app:stable, yet the meaning of stable changed.
Keep the readable tag in your release record. Pin the deployed image to its SHA-256 digest, then make digest updates a normal reviewed change.
Know what the digest fixes
A digest identifies content in the registry. Docker can pull an image with a reference such as registry.example/app@sha256:.... A registry tag may move; that digest reference does not.
Kubernetes also accepts a digest. Its documentation explains that digest pinning prevents a changed tag from leaving a workload with a mix of old and new code. You may write both a tag and digest for human context, but Kubernetes uses the digest to pull.
That makes repeat runs match. It does not tell you who built the image. It does not show whether the source was reviewed or a dependency is weak. Treat image identity, publisher trust and risk as three separate checks.
| Question | Control | What it proves |
|---|---|---|
| Which bytes will run? | Digest pin | The registry manifest has the expected identity |
| Who approved or built it? | Signature policy | The image matches a trusted signer or CI identity |
| What is inside? | SBOM, scan and tests | Evidence about components, flaws and behaviour |
| Can we recover? | Recorded prior digest | A precise rollback target exists |
Do not confuse pulling with pinning
imagePullPolicy: Always is not an immutability control. For a tag, Kubernetes resolves the name to a digest whenever it launches a container. If the tag moved, a later Pod can receive new content.
When a workload specifies a digest and omits the pull policy, Kubernetes currently sets IfNotPresent. The policy is fixed when the object is first created; changing the image reference later does not automatically rewrite that field.
Set the pull policy for your operating model, but make the digest the release identity. Cache use is safe when the cached image matches that digest.
Resolve a tag before deployment
Choose one place in the pipeline to turn the approved tag into a digest. Resolve it from the registry after the image is pushed, not from a developer note or a copied console line.
Record the registry, repository, tag, digest, build run and source revision together. Multi-platform images add one caveat: the top-level digest can identify an image index that points to separate platform manifests. Record the index digest and the tested platforms.
Keep the registry object available for the life of the release. A perfect reference is not useful if retention cleanup deletes the image. Mirror critical third-party images into a controlled registry when your recovery plan requires that independence.
Verify trust before you freeze the reference
A signature check belongs before approval. With Sigstore Cosign, verification can constrain the certificate identity and issuer for keyless signatures. Pinning a digest without checking the expected identity only preserves whatever was selected.
Define the exact publisher identity that your policy accepts. Save the verification result with the release evidence. An attestation can add build or provenance facts, but it still is not a malware verdict.
Review the image's components as well. The SBOM review workflow helps test scope and freshness. Use the KEV and SSVC triage method when findings need a patch order.
Automate the change, not the bypass
- Discover. A bot or scheduled job reads the allowed upstream tag and resolves its current digest.
- Verify. Check the expected signer, issuer and any required attestations.
- Propose. Open a change that shows the old digest, new digest, tag and release notes.
- Test. Build and scan the exact candidate, then deploy it to a limited environment.
- Promote. Approve the digest through the normal production path and watch health signals.
- Retain. Keep the prior digest available until the rollback window closes.
Do not let the updater edit production outside review just because the upstream tag is familiar. A support deadline may justify speed, but not an invisible change. Track those deadlines with the software support calendar.
Run a rollback drill with a harmless service. This is a procedure for your team to test; TechWeb did not inspect your registry or cluster. The restore-test guide offers the same proof-first mindset for data.
Frequently asked questions
Is a version tag such as v2.4.1 immutable?
Not by the container reference rules. A registry owner can reuse a tag unless the registry or policy prevents it. Resolve and pin the digest.
Does imagePullPolicy Always make a tag safe?
No. It asks Kubernetes to resolve the image when a container starts. If the tag moved, the result can change.
Does a digest prove an image is secure?
No. It proves content identity. Verify the publisher, inspect provenance, scan components and test the exact image.
What should a rollback record contain?
Keep the prior digest, configuration version, database compatibility note and the point at which rollback is still safe.
Sources
Docker Docs: Image digests · Docker Docs: Pull by digest · Kubernetes Docs: Images · OCI Image Specification: Manifest · Sigstore Docs: Verify signatures. Registry controls and command syntax can change; check the live documentation for your platform.
More in this sectionTechnology →