Identity, authentication, and authorization
Knowing who made a request is necessary, but it does not answer what the requester may do. This project uses identity in three distinct places: to access GCP storage, to authenticate signed statements, and to let cluster controllers read and evaluate those statements. Deployment selection adds another authorization decision through Git review.
- Cloud path: GitHub token exchanges through federation for short-lived GCP service-account access.
- The CI cloud account publishes/reads registry content under IAM.
- Signing path: the workflow obtains keyless identity for the canonical sign-attest.yml at refs/heads/main.
- Fulcio certificate and Rekor evidence support Cosign verification against subject and issuer.
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.
Cloud authentication grants storage access
Section titled “Cloud authentication grants storage access”The composite GCP-auth action uses GitHub OIDC and the configured Workload Identity provider to impersonate supply-chain-ci. Terraform grants that service account repository-scoped Artifact Registry writer access on two repositories. This avoids a stored GCP service-account JSON key for the CI path.
The provider maps token claims including repository, owner, ref, actor, and workflow. Its attribute condition checks the repository name. Mapping a ref is not the same as requiring that ref. The actual baseline’s main-only release authority therefore also depends on the Deploy workflow’s job conditions. Describing federation itself as “main-only” would overstate the source configuration.
The intended least privilege is narrower than project-wide administrator access, but it is not a separate cloud principal for each build, signing, and CI verification job. Those jobs use the supplied CI identity. Changing trusted workflow code can consequently affect both artifact publication and the claims produced about it.
Signing authentication grants claim origin
Section titled “Signing authentication grants claim origin”Cosign obtains a keyless signing identity through the GitHub/Sigstore path. The certificate subject trusted by this baseline is:
https://github.com/devSatym/gcp-supply-chain-security/.github/workflows/sign-attest.yml@refs/heads/mainThe trusted OIDC issuer is https://token.actions.githubusercontent.com. CI constructs the subject from github.repository; admission contains the canonical repository’s exact subject. Those bindings explain why a fork or tag checkout cannot simply reproduce the original trust contract unchanged.
A verifier checks that the certificate and signature authenticate the expected workflow claim. It does not infer that the signer was an uncompromised workflow. A compromised approved workflow can still satisfy its expected identity. Short-lived credentials reduce the risk of an enduring stolen key, while preserving the need to protect workflow execution itself.
Admission reads without publishing
Section titled “Admission reads without publishing”Kyverno’s admission-controller Kubernetes ServiceAccount is bound through GKE Workload Identity to a dedicated kyverno-verifier GCP service account. That principal receives reader access on both the application and metadata repositories. It can retrieve evidence without being given the CI writer’s storage authority.
The values file annotates the Kubernetes ServiceAccount with the GCP principal. Terraform’s binding names kyverno/kyverno-admission-controller exactly. A mismatch between the installed service account, annotation, binding, or repository grant can cause retrieval errors. That is an authentication/access failure, distinct from a retrieved signature failing the expected subject or issuer check.
The absence of a JSON key in this path is a source-backed property. It does not establish every historical component was key-free: the repository preserves a Ratify authentication trade-off and older infrastructure paths. The active Kyverno path should be evaluated separately from those historical alternatives.
Selecting a release is authorization
Section titled “Selecting a release is authorization”A repository maintainer’s reviewed Helm digest change chooses an artifact for the GCP release. Neither possession of a registry writer role nor creation of a valid signature automatically makes that choice. Argo CD then applies desired state with its cluster permissions. Kyverno decides whether the resulting matching workload satisfies admission requirements.
Treat these as separate questions when troubleshooting: can this actor access storage, who authenticated this statement, who selected this digest, and which request may enter this cluster scope? Mixing them leads to dangerous fixes, such as granting writer access to a verifier or weakening signer identity to solve a registry read failure.
What is demonstrated
Section titled “What is demonstrated”The source defines the cloud and workload-identity bindings. Historical verification captures show the expected signing subject and issuer; acceptance and denial captures show selected admission outcomes. This documentation task did not exchange a new cloud token or inspect effective live IAM.
Continue with a valid signature is not enough to see how authenticated origin becomes a narrower, field-specific decision.