Skip to content
About

From source code to trusted execution

A build creates an artifact. A connected security design decides whether it may run—and what we must still observe after it starts. Explore the decisions, their evidence, and their limits.
GCP SECURITY ARCHITECTURE HANDBOOK01 / HISTORICAL EDITIONBUILD · VERIFY · ADMIT · OBSERVE

Who can publish an image? Who endorses its origin? Who selects the release? Who evaluates the request to run it? These are different authorities, even when they act on the same immutable digest.

One delivery system, several decisions
One delivery system, several decisionsGitHub 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.Source & CIRegistry claimsGitOps & policyRuntime events
Historical GCP system: source changes produce artifacts; Git selects a digest; admission evaluates a request; runtime observes execution.
  1. GitHub Actions evaluates changes and builds the digest.
  2. Artifact Registry stores the image and separately stored signatures/attestations.
  3. A human selects the digest in Git; Argo requests reconciliation and Kyverno evaluates admission.
  4. 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.

The connected design · select a stage to inspect its handoff

01 / Review a change

Can this change safely enter the trusted build path?

Input: PR revision. Output: Checks without publish authority. Verifier: PR checks.

Read this stage →
02 / Build exact content

Which artifact did the release checks evaluate?

Input: Trusted main revision. Output: Image digest. Verifier: Trivy.

Read this stage →
03 / Sign the digest

Which workflow endorsed these exact bytes?

Input: Digest and workflow identity. Output: Signature. Verifier: Cosign.

Read this stage →
04 / Select a release

Which verified digest is permitted to run?

Input: Verified digest. Output: Reviewed Git digest pin. Verifier: Reviewer and Argo CD.

Read this stage →
05 / Decide admission

Does the requested image meet this namespace and registry policy?

Input: Requested Pod image. Output: Allow or deny. Verifier: Kyverno.

Read this stage →
06 / Observe runtime

What does an admitted process do next?

Input: Running process events. Output: Detection. Verifier: Falco.

Read this stage →

You can understand the whole design without reading every prerequisite first. Start with the questions that matter to your review.

Recorded acceptance

A trusted digest enters the workload

The historical evidence records a digest-pinned workload running under the configured trust policy. This establishes the tested path in that environment.

Read the allow and deny evidence →
Recorded rejection

An unsigned image meets a boundary

The matching unsigned image is rejected at admission. Unmatched registries, excluded namespaces, and untested subresources remain separate questions.

Inspect the exact policy scope →

The edition is pinned to the preserved GCP implementation, not current main’s Azure system. Code inspection, local tests, and historical captures carry separate labels. A valid signature establishes an authenticated claim; it does not make the application invulnerable.

Read the baseline boundaries, browse the evidence catalogue or all fourteen screenshots, or inspect the canonical project. Upstream attribution and primary references are recorded in the reference index.

More engineering projects

Each project has its own documentation. Planned sites are listed as destinations under preparation.

Documentation planned

Resilience Gate

A planned independent project documentation site. Its scope and evidence will be described when a reviewed edition is available.

Proposed hostname resilience.devsatym.xyz

Documentation planned

Azure AKS GitOps Observability

A planned independent documentation site for the AKS, GitOps, and observability project. This GCP handbook makes no claims about its deployed state.

Proposed hostname aks.devsatym.xyz

GCP Security Architecture Handbook: build, verify, admit, observe. Maintained by Satyam Agnihotri, devSatym.
Original editorial artwork for this handbook. This illustration is separate from the recorded implementation evidence.