Assets, threats, and the security model
The valuable outcome is a workload whose origin and selection can be explained, and whose behavior can still be observed after it starts. Protecting a registry password alone would leave the more important question unanswered: who may cause particular code to execute in the cluster?
The preserved GCP system answers that question with several decisions. Pull requests receive static validation and a local container scan. Selected main-branch runs may publish an image. A signing workflow records authenticated claims about that digest. Continuous integration (CI) checks those claims. A reviewed Git change selects a digest for Argo CD to reconcile. Kyverno evaluates matching images at admission. Falco watches process behavior after execution begins. Each stage protects a different property; none makes the application universally safe.
- GitHub Actions evaluates changes and builds the digest.
- Artifact Registry stores the image and separately stored signatures/attestations.
- A human selects the digest in Git; Argo requests reconciliation and Kyverno evaluates admission.
- Falco detects configured execution events after the workload starts.
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.
What is valuable
Section titled “What is valuable”The first asset is execution authority: permission to change the code and configuration that the cluster runs. The source repository, workflow definitions, Helm digest value, Argo Application, and admission policy all influence that authority. The second asset is artifact identity: the exact container image bytes selected for release. Its digest connects the build output, signature, attestations, GitOps selection, and runtime image reference.
The third asset is claim integrity. An image signature, software bill of materials (SBOM), and provenance record should be bound to the intended artifact and approved workflow identity. Their usefulness depends on truthful production as well as correct verification. The fourth asset is operational visibility: admission errors, verification logs, process events, and preserved evidence needed to diagnose failures and respond to unexpected behavior.
Repository-scoped Artifact Registry writer and reader permissions protect cloud access, but cloud authorization is one part of this model. A valid cloud credential does not establish that an image was signed by the expected GitHub workflow; a valid signature does not authorize someone to choose that image for deployment.
Threats this design addresses
Section titled “Threats this design addresses”| Actor or failure | Unsafe outcome | Decision intended to interrupt it |
|---|---|---|
| Untrusted contributor | PR code obtains registry publishing or signing authority | PR job permissions and main-branch job conditions |
| Accidental release selection | A mutable tag selects different bytes than reviewed | Digest reference in Helm values and template |
| Publisher without approved signing identity | A matching unsigned image reaches a Pod | Signature and attestation checks at admission |
| Fork or different workflow | Valid cryptographic claim from an unexpected origin is accepted | Exact certificate subject, issuer, and provenance conditions |
| Mixed Pod request | A trusted application image distracts from an unsigned init image | Verification of the image fields exercised by the recorded fixtures |
| Unexpected process after admission | A permitted image launches a shell without visibility | Falco process detection in its configured namespace scope |
| Broken verifier or claim format | Good releases are denied or bad claims overlooked | CI verification, fixture checks, operational diagnosis and evidence review |
These are source-backed threat scenarios, not a claim that every possible attack was tested. The evidence section distinguishes inspected controls from recorded results.
Where attackers could act
Section titled “Where attackers could act”The attack surface includes repository changes, workflow execution and dependencies, cloud federation, both registry repositories, GitOps selection, cluster policy configuration, admission-controller availability, and the running application. An attacker who can edit the trusted workflow may produce malicious bytes and signed, internally consistent claims. An administrator who can exempt namespaces or remove admission configuration can alter enforcement. A runtime vulnerability remains possible even if all checks approve the image.
The Dockerfile uses a tagged Python base and resolves packages during the build. This makes the build inputs broader than the application’s Git commit. Dependency resolution, upstream packages, and runner integrity remain trust dependencies. A pinned final image digest preserves the chosen output; it does not establish a reproducible or network-independent build.
Assumptions and non-goals
Section titled “Assumptions and non-goals”The design assumes that the canonical repository, its maintainers, GitHub’s identity issuance, Sigstore trust services, GCP identity services, and the cluster control plane behave as expected. Source definitions such as CODEOWNERS express review intent; this inspection does not establish enforced remote branch rules or required reviewers.
This handbook documents a historical demonstration. It does not attest that a cluster is running today, establish a SLSA assurance level, prove SBOM completeness, block every image in every namespace, or provide a tested automatic incident response. Those limitations shape the control contracts rather than being hidden behind the phrase “defense in depth”.
The useful next step is to trace where authority changes hands. The security model is strongest when the reader can name the input, verifier, and remaining assumption at every boundary.
Implementation sources
Section titled “Implementation sources”- Deploy workflow: event conditions and authority split.
- Supply-chain infrastructure: federation and registry permissions.
- Admission policy: matching images, required claims, exclusions.
- Runtime rule: process condition and output.