Wire registry, federation, verifier, and GitOps

A release passes through several authorities. The GitHub job needs registry write access; the signing workflow needs a verifiable certificate identity; Kyverno needs registry read access and exact expected claims; Argo CD needs a reviewed Git revision. Success in one exchange cannot substitute for success in another.

Registry addresses

Terraform creates an application repository with immutable tags and a separate metadata repository with mutable tags. Cosign v2’s legacy signature and attestation indexes need updates as statements are appended. COSIGN_REPOSITORY redirects those objects; they remain cryptographically bound to the application’s immutable digest.

Keep GAR_LOCATION, GAR_PROJECT_ID, GAR_REPOSITORY, and COSIGN_REPOSITORY consistent across the GitHub repository variables and owned policy. The metadata repository includes an image path, not just the repository ID. Kyverno’s policy uses its repository field to read that same metadata location. Grant CI writer access to both repositories and Kyverno reader access to both.

GitHub-to-Google cloud federation

Set GCP_WORKLOAD_IDENTITY_PROVIDER to the provider’s full resource name and GCP_SA_EMAIL to the dedicated CI account. The composite GCP authentication action exchanges a GitHub OIDC token and configures Docker for the GAR host.

The historical provider condition checks the canonical repository. Although it maps assertion.ref, it does not constrain that ref in the provider condition or service-account binding. The Deploy workflow restricts privileged jobs to refs/heads/main; that is a workflow-level boundary. Do not describe federation as independently enforcing a main-only claim. Protect workflow changes and verify live repository settings separately.

Signing identity and provenance

The expected certificate subject is the reusable signing workflow, .github/workflows/sign-attest.yml@refs/heads/main, with issuer https://token.actions.githubusercontent.com. It is not the Google service-account email and not deploy.yml or verify.yml. The producer derives the provenance entry point from the OIDC token’s job_workflow_ref claim; the verifier expects .github/workflows/sign-attest.yml.

In an owned fork, change every related expectation deliberately. The Terraform variable’s canonical-repository validation must also be intentionally adapted in the reproduction copy. Merely changing GitHub variables, checking out the tag, or renaming a workflow cannot satisfy the original identity contract.

Kubernetes-to-Google reader identity

The root binds Kubernetes service account kyverno/kyverno-admission-controller to its verifier GSA using roles/iam.workloadIdentityUser. The Helm values annotate the admission-controller account with that GSA’s email. Verify the rendered account name for the chart version you install: an annotation on the wrong account is inert even if the IAM grant is correct.

The policy matches Pod images in the protected application registry pattern and excludes five system namespaces. An image outside that pattern is outside this signature policy; it is not proof of a successful cryptographic check. Compare the CI and admission contracts before expanding scope.

GitOps desired-state source

The historical Application points to the canonical repository, targetRevision: main, and k8s/helm/supply-chain-demo. Automated prune and self-heal make that Git state authoritative. Current canonical main is Azure, so applying this historical Application unchanged today would track a different revision than the handbook baseline.

For reproduction, choose an owned branch and repository holding the reviewed GCP configuration, then adapt the Application there. Record that new source revision with the trust expectations. Never point an owned reproduction at a changing branch whose content you have not reviewed.

Source anchors

Registry and federation bindings, Kyverno reader values, and Argo Application.