Why a successful build is not permission to deploy

A build turns source into runnable bytes. Deployment grants those bytes access to compute, network, and whatever authority the workload holds. Moving directly from “the compiler succeeded” to “run this container” would skip questions about known vulnerabilities, origin, release selection, and the deployment boundary.

This baseline makes those questions visible. It first validates a proposed change without registry publication or signing authority. Trusted main can then produce a digest, scan that exact artifact, sign it, attach claims, and verify those claims. An operator still has to choose a verified digest in the Helm values. Argo CD reconciles that Git choice; Kyverno evaluates in-scope images before the API accepts the workload. Falco observes behavior after it starts.

One digest across the handoffs

Illustrative identity D = sha256:<build-output>. This is a reading guide, not live verification.

1. Review a change

   PR revision → Checks without publish authority. Checked by PR checks.

2. Authenticate to GCP

   GitHub OIDC token → Registry authority. Checked by GCP IAM.

3. Build exact content

   Trusted main revision → Image digest. Checked by Trivy.

4. Sign the digest

   Digest and workflow identity → Signature. Checked by Cosign.

5. Attach statements

   Image and build context → SBOM and provenance. Checked by Cosign.

6. Verify release claims

   Digest and statements → Release verification. Checked by Cosign and jq.

7. Select a release

   Verified digest → Reviewed Git digest pin. Checked by Reviewer and Argo CD.

8. Decide admission

   Requested Pod image → Allow or deny. Checked by Kyverno.

9. Observe runtime

   Running process events → Detection. Checked by Falco.

One artifact, several decisions

Use the historical selected digest as a concrete example:

sha256:32a90d832fdf76794fa5477e42e1fdcec28c9eb6e0deee48ad466d1f7d9fc563

That string is stored in the Helm values. It identifies the artifact selected in desired state. It does not identify the documentation revision, prove that every dependency is safe, or imply that the artifact was built from the same commit that selected it.

The build output supplies an artifact identity. The scanner supplies a result under a configured severity/exception policy. The signature supplies a statement from the accepted workflow identity. The SBOM supplies an inventory; provenance supplies workflow-generated origin assertions. CI compares those statements to the digest and source context of the current run. Promotion chooses one artifact. Admission evaluates the request presented at that later boundary.

A verified artifact still needs a release choice

GCP promotion is a reviewed manual digest edit, followed by reconciliation and admission.

1. CI verifies digest-bound identity and statement fields for its own build.
2. A human reviews and commits the selected digest into Helm values.
3. Argo CD reads desired state from the canonical main branch and requests objects.
4. Kyverno verifies the matching images at the execution boundary.

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.

Where authority changes

The first authority change occurs when source becomes trusted main. Source definitions provide workflow conditions and CODEOWNERS, but do not themselves prove remote merge protections are enabled. The second occurs when GitHub OIDC is exchanged for registry access. The third occurs when the signing workflow makes a cryptographic claim. The fourth is the operator’s desired-state update. The fifth is Kubernetes admission.

These actors do not have equivalent powers. A scanner can report a finding but does not select a release. A valid signer can attest an artifact but does not make it the desired release. Argo CD can reconcile the release but does not perform Kyverno’s image verification. Falco can emit a suspicious-event record but does not revoke the original admission decision.

The exact caller guards and dependency sequence are in the release orchestrator. The workflow named Deploy does not update Helm values or call the cluster. Its implemented output is a built, signed, attested, verified artifact; the GCP promotion remains manual.

Follow the failure path too

A relevant PR with blocking findings should fail its checks. A main image scan failure occurs after registry push and prevents the dependent signing job; the rejected image may still exist in the registry. Missing or mismatched verification statements fail CI. Missing required signatures/attestations deny matching admission requests. A runtime shell event is an observation after permission to run was granted.

Policy scope matters at every step. Image admission matches one historical registry prefix and excludes named system namespaces. The final CI provenance contract checks the run’s source commit and matching source material; admission checks builder, workflow entrypoint, and source URI without selecting a source commit. There is no claim that these stages are exhaustive or independent trust roots.

What was observed

The owner record reports the earlier digest running through Argo CD and records trusted/unsigned admission and controlled shell results. A later strict CI record describes a newer verified digest that was deliberately not selected in Helm. That separation is evidence of a release selection boundary, rather than proof of automatic deployment.

Begin with PR validation, or jump to CI verification if you want the exact claim comparison. At each stage, distinguish artifact production, trustworthy statements, release permission, and behavior after admission.