Where authority changes hands
A release is a sequence of permissions granted by different actors. Code moving between systems is not the same as authority moving between them. The important boundary is the point where one actor begins relying on another actor’s claim or selection.
- A contributor proposes source and workflow changes; review enforcement requires remote settings.
- Workflow guards give the main execution path cloud and signing authority.
- A reviewed Git change selects the immutable release digest.
- Kyverno controls matching admission requests; operator/policy changes can alter that 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.
Contribution to trusted workflow execution
Section titled “Contribution to trusted workflow execution”A contributor may propose source changes without being permitted to publish a release. The baseline Deploy workflow triggers on pull requests, but its PR image-scan job has read-only contents access and security-results upload permission. It builds locally with push: false. Build, signing, and verification jobs are guarded by refs/heads/main; publishing additionally requires a push or the confirmed manual input.
That event and permission split prevents the documented PR path from acquiring release privileges. It depends on the workflow’s conditions staying correct. A main-branch workflow edit changes the mechanism that decides which events get authority. CODEOWNERS names the owner for sensitive files, but the file alone is not evidence that an external ruleset requires review.
Workflow to cloud registry
Section titled “Workflow to cloud registry”GitHub OpenID Connect (OIDC) tokens are exchanged through GCP Workload Identity Federation to impersonate the CI service account. Artifact Registry grants that account writer access on the application and Cosign metadata repositories. The infrastructure’s federation condition accepts the configured repository; it does not independently require the main branch. Main-branch restriction is therefore implemented by workflow gates in this baseline.
The registry trusts the cloud principal for storage operations. It does not decide whether a digest is suitable for deployment. A compromised writer could add unwanted objects; consumers still need their own origin and selection checks. Registry immutability helps prevent replacing tagged application objects, while a separate mutable repository supports legacy Cosign metadata indexes.
Workflow identity to signed claim
Section titled “Workflow identity to signed claim”Sigstore keyless signing binds a short-lived signing certificate to the GitHub signing workflow identity. The expected subject includes the canonical repository, sign-attest.yml, and refs/heads/main. This is a distinct exchange from cloud federation. The GCP service account authorizes registry access; it is not the certificate subject the verifiers trust.
Verifiers rely on the signer being authorized and on the workflow producing truthful data. The certificate authenticates origin, not the correctness of every statement in a manually generated provenance predicate. The signature explanation follows that distinction through the exact CI and admission fields.
Verification to release selection
Section titled “Verification to release selection”CI verification produces a result about the candidate digest. The GCP workflow does not automatically edit the GitOps digest value. A reviewed change to Helm values selects the artifact. This keeps release selection as a separate authorization decision: a successful build is available for consideration, while the manifest expresses what should run.
Argo CD reads the Helm path from canonical main and reconciles it to the default namespace. Its prune and selfHeal settings maintain desired state. Argo CD does not replace Kyverno’s cryptographic checks. Its Kubernetes writes still pass through the admission boundary, subject to the actual policy match and webhook configuration.
API request to execution
Section titled “API request to execution”Kyverno evaluates claims for the configured application-registry path outside five excluded namespaces. The API server’s acceptance allows controllers and the scheduler to move toward execution. A server dry run exercises the admission request without persisting the requested resource. A healthy Argo Application and running replicas are a separate observation that execution happened historically.
Admission is a decision about a request at a moment in time. It is not continuous process authorization. The runtime rule observes shell launches after admission; it cannot retroactively make the admission claim stronger. It also has a different namespace exclusion list from the signature policy.
Boundaries that remain unverified
Section titled “Boundaries that remain unverified”This review does not query live repository protections, cloud IAM state, installed webhook configurations, or current controller availability. Historical captures show selected outcomes, and source inspection explains the intended contract. They do not establish today’s boundary state or a tested recovery from a compromised controller.
The strongest review question at each handoff is: which later component relies on this output, and what would happen if it were wrong? Follow that question into shared failures.