A connected security design
A container that builds successfully may still contain an exploitable dependency, originate from an untrusted workflow, or be the wrong version for deployment. Even an approved container may behave unexpectedly after it starts. This handbook follows the decisions that turn a proposed code change into a particular running workload, then asks what those decisions leave unresolved.
The example is a small FastAPI service. Its simplicity makes the security path visible: GitHub Actions builds and scans an image, Google Artifact Registry stores it, Sigstore binds statements to its digest, an operator selects a verified digest in Git, Argo CD reconciles that selection, Kyverno verifies matching images at admission, and Falco observes selected runtime behavior. Each component answers a different question. A successful answer at one boundary does not automatically answer the next.
- 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 the project demonstrates
Section titled “What the project demonstrates”The important object is the image digest, a content identifier carried from the build output into signing, attestations, verification, and the Helm workload definition. The digest keeps those stages discussing the same artifact. The important authority is the trusted workflow identity, which tells a verifier whose statement it is accepting. The important deployment decision is the reviewed change to desired state, which chooses which verified artifact should run.
The preserved GCP workflow separates pull request validation from main-branch artifact publication. It uses short-lived cloud authentication, signs with a GitHub workflow identity, requires signature/SBOM/provenance checks in CI, and configures admission checks for a specific registry prefix outside excluded system namespaces. The deployed chart adds non-root execution, a read-only filesystem, dropped capabilities, and a default seccomp profile. Runtime rules then detect an unexpected shell process.
These properties are visible in the release orchestrator, the admission policy, and the workload template.
Read the evidence with the implementation
Section titled “Read the evidence with the implementation”Historical owner validation records acceptance of the selected signed digest, rejection of an unsigned artifact, rejection of mixed-container and unsigned-initContainer fixtures, and detection of a controlled runtime shell. The wrong-trust experiment changes signer and provenance expectations together; it is one combined experiment. Optional Discord alert delivery was not captured. None of these records establishes that a cluster is running today.
The scope page distinguishes the implementation snapshot, evidence revisions, and current Azure main branch. The site explains that historical design without changing or restarting its infrastructure. It does not certify every dependency, establish a SLSA assurance level, prove branch protection is enforced, or claim universal admission coverage.
Choose a useful first route
Section titled “Choose a useful first route”- Take the guided tour to inspect one artifact, one denial, and one runtime observation.
- Follow a release to understand inputs, authority, and failure handling at each stage.
- Study the security model to examine assets, assumptions, and shared trust dependencies.
- Use safe local inspection before considering an owned historical reproduction.
The question to carry through every route is: which claim has just been established, who established it, and which later decision still has to be made?