Select a verified digest and reconcile Git

A registry can contain many verified images. Selecting one to run is an authorization decision about desired state, not a side effect of image publication. The GCP baseline makes that choice through a reviewed manual digest update in the Helm chart. It has no automatic GitHub Actions promotion job.

Security decision · promotion

Which verified digest is permitted to run?

Required property

Human reviews and commits a digest pin; Argo reconciles Git

Responsible control

Helm values and Argo CD

Scope

Historical canonical main chart

Failure behavior

Bad or uncommitted selection prevents intended reconciliation; admission still evaluates images

Limit

Remote reviewer enforcement unconfirmed · Argo health is not signature verification

Follow the same immutable identity

Illustrative identity D represents one digest; it is not a recorded deployment digest.

1. The build output identifies an OCI manifest by digest D.
2. The signature, SPDX SBOM and provenance bind claims to D; authenticity does not guarantee safety.
3. Helm values reference D rather than a mutable tag.
4. Admission checks the requested image D and the associated trust metadata.

Solid arrows indicate the stated handoff, not a claim of independent trust. Optional relationships are described in the text equivalent. Historical components are labeled in the caption.

The promotion record

The Helm values contain a repository and the selected SHA-256 digest. The template renders that pair as repository@digest. An operator reviewing a promotion should connect the candidate digest to its source run, verification result, accepted scan exceptions, and intended rollout.

The source change that selects an image may be newer than the source used to build it. A promotion commit changes desired state; it does not rebuild the selected artifact. The historical CI audit attributes the deployed 32a90… digest to source e369771… and says 9bf574c… subsequently pinned it. Treat those as separate events even when another summary mentions a successful run on the promotion commit.

The later hardened main run produced a verified a0073… digest, while the status record deliberately retained the earlier digest pending reviewed promotion. A green pipeline therefore does not automatically change the workload.

Argo CD carries the selected state

The Argo Application points to the canonical repository’s main branch and k8s/helm/supply-chain-demo, with release name supply-chain-demo, destination namespace default, and automated prune and selfHeal. Argo CD renders the chart and reconciles desired state into the cluster.

Argo CD establishes consistency with its configured Git source. It does not perform the policy’s signature verification. The Kubernetes API still sends the resulting in-scope workload through Kyverno admission. A chart rendering successfully or an Argo sync beginning is not proof that the Pod was accepted; policy rejection can leave the Application degraded or out of sync.

Self-healing also affects operational changes: a manual modification to an Argo-managed object can be restored to the Git definition. An emergency response must account for reconciliation before assuming a cluster-only edit will persist. The historical negative-test Application is separately configured without automatic synchronization to avoid endlessly retrying known denials.

Review is a process claim

This handbook describes reviewed manual promotion as the baseline’s intended operating procedure. Source alone cannot establish that every historical change received an approving human review. CODEOWNERS and an unapplied ruleset do not provide that proof. The meaningful observable configuration is that publication does not update the selected digest and that desired state is tracked in Git.

Rolling back desired state means selecting an earlier appropriate verified digest, not replacing the chosen tag with arbitrary bytes. Historical provenance remains associated with the artifact’s build source, while the rollback commit records a new deployment selection.

Reproduction caveat

The original Application follows canonical main, which now implements Azure and no longer contains this GCP chart. A detached checkout of the GCP tag does not change the Application’s remote source. An owned reproduction must deliberately bind GitOps to the owned preserved source while aligning signing identity and federation; see first release.

Continue with the admission decision. The selected digest says what should run; admission asks whether this particular request satisfies the enforced in-scope image contract.