Executive Summary
The container image digest verification system provides cryptographic assurance that every container running on a validator node matches the exact version pinned and signed by the fleet controller. This prevents supply-chain attacks where modified container images could compromise consensus operations.
Verification Protocol
Each validator node maintains a local inventory of all running container images. During bootstrap Gate 3, the node computes SHA-256 digests for each image and transmits them to the fleet controller for comparison against the centrally pinned manifest stored in hq_image_digests.
| Step | Action | Failure Mode |
|---|---|---|
| 1 | Enumerate all local container images (17+) | Incomplete inventory halts bootstrap |
| 2 | Compute SHA-256 digest for each image | Computation failure halts bootstrap |
| 3 | Submit digest list to fleet controller | Network failure triggers retry |
| 4 | Controller compares against pinned manifest | Any mismatch halts bootstrap |
| 5 | Controller returns signed approval | Missing approval halts bootstrap |
Pinned Manifest Management
The fleet controller maintains the authoritative manifest of approved image digests. When a new image version is deployed through the secure image pipeline, its digest is registered, signed, and pinned in the manifest. The pipeline flow is: DevNet build, push to Artifact Registry, JILHQ register and sign, validators pull on refresh, digest verify before deploy.
Implementation Details
The verification service runs as part of the validator update agent. It compares digests at bootstrap and optionally during periodic health checks (every 60 seconds via the AI Fleet Inspector).
// Image digest table schema
CREATE TABLE hq_image_digests (
service_name TEXT NOT NULL,
image_tag TEXT NOT NULL,
sha256_digest TEXT NOT NULL,
signed_by TEXT NOT NULL,
pinned_at TIMESTAMPTZ DEFAULT NOW(),
PRIMARY KEY (service_name, image_tag)
);