Trusted Images, Harbor, and Signing
Intro: Registry trust is where build security becomes deployment security. A team that scans code but promotes untrusted or unsigned images still has a weak supply chain.
Core ideas
- curated base images;
- private registry controls;
- image scanning before promotion;
- signing and verification before deployment;
- traceability from source revision to artifact digest.
Why provenance matters
The critical question is not only “did the scanner pass?” but also:
- where did the image come from?
- who built it?
- what exactly is inside it?
- can we prove the promoted image is the one we intended to run?
Practical Harbor-oriented pattern
Promotion tiers
- sandbox — developer experimentation and short-lived builds;
- integration — scanned candidate images;
- release — approved and signed images only;
- production mirror — tightly controlled pull source.
Minimum policy expectations
- only approved projects or robot accounts may push to release repos;
- vulnerability gates apply before promotion;
- tags used for humans, digests used for precise deployment decisions;
- retention rules prevent old and confusing artifacts from accumulating;
- audit logs retained for push, delete, retag, and project-policy changes.
Signing and verification model
A practical image-trust story usually includes:
- build image;
- scan image;
- generate SBOM;
- sign the image after it passes policy;
- verify signature or trust policy before deploy.
What to store as release evidence
- source revision;
- build pipeline identifier;
- image digest;
- scanner result summary;
- signing event and signer identity;
- environment promotion decision.
Common mistakes
- trusting tags instead of digests for production deploys;
- scanning once in dev but not again at release time;
- allowing direct push into high-trust registries;
- mixing public and internal artifacts in the same trust tier;
- no process to rebuild and republish when base images change.