Decisions, trade-offs, and deferred controls

Security architecture allocates authority and accepts operating costs. The following decisions summarize executable behavior and source-backed context. Explanations marked as interpretation clarify the trade-off; they do not invent a historical approval record.

Separate cloud access from signing identity

The active path uses short-lived federation for GitHub-to-Google access and GKE Workload Identity for Kyverno registry reads. Cosign keyless signing obtains a workflow-bound Sigstore certificate separately. This avoids a stored signing private key or cloud JSON key on the active path, while making GitHub, federation configuration, and the signing workflow shared trust dependencies.

Interpretation: a long-lived key could simplify a tool integration but adds storage, rotation, and disclosure risk. Keyless identity improves credential lifetime and attribution; it does not protect against a trusted workflow that is modified maliciously. The baseline provider is repository-bound rather than ref-bound, so reviewed workflow conditions matter.

Split application and metadata repositories

Application tags are immutable. Cosign v2’s legacy statement indexes require mutable tags as SBOM and provenance statements are appended. A separate mutable metadata repository accommodates that storage model while statement signatures still bind to the selected image digest.

The consequence is two address and IAM contracts that must stay aligned. Registry authority can delete or disrupt required metadata, harming admission availability. Mutable metadata storage does not make an attacker-supplied statement valid under the pinned signer expectation, but it remains part of the availability and evidence-retention boundary.

Manual digest promotion

The GCP workflow builds, scans, signs, and verifies, then stops. A maintainer reviews the verified digest and commits it to Helm values. Argo CD reconciles that chosen Git state. This separates artifact production from release selection and explains why a newer successful CI artifact is not automatically running.

Interpretation: automation could reduce delay but requires an explicit selection authority and review policy. It is absent in this baseline. Do not import the current Azure automated promotion design into the GCP narrative. Manual review is intended process; it does not prove a remote required-review rule exists.

Kyverno is the active admission engine

The final policy expresses signature, SPDX attestation, and SLSA provenance verification together with registry/namespace scope. The baseline has personal GCP captures of allow and deny paths. Retained Gatekeeper/Ratify policies and the static-key ADR describe an earlier integration; enable_legacy_ratify: false disables its Terraform resources.

The historical Ratify ADR discusses missing GCP authentication support and credential-cache lifetimes as reasons for a JSON-key exception. Those historical upstream observations are not a current vendor compatibility audit. They explain retained code; they do not require the active Kyverno path to create a key. Reassess primary version-specific support before ever reviving that design in an owned environment.

Limit admission scope deliberately

The policy protects a configured GAR pattern and excludes infrastructure namespaces. This reduces immediate system-workload compatibility friction but leaves unmatched images outside the supply-chain check. CI provenance checks are stronger than admission’s explicit predicates on source commit and materials. Both share the trusted producer.

Enforcement also has an availability cost: metadata access, statement size, and webhook health affect decisions. The baseline values allow an 8 MiB context; actual outage handling must be assessed from deployed webhook configuration. The evidence does not justify a universal cluster-wide, fail-closed, all-container-path claim.

Runtime detection and optional delivery

Falco observes behavior after admission. Its custom shell rule is a strong signal for this small HTTP service, but the condition does not verify a signature and cannot prevent the shell. rule_matching: all avoids a broader default rule swallowing the custom event. External Pub/Sub → function → Discord routing remains opt-in and unverified while disabled.

Deferred controls and evidence limits

The historical handoff identifies branch-ruleset activation and an owned blocking IaC/misconfiguration scan baseline as remaining work. The source ruleset omits required approving reviews for the single-maintainer case. Exception rationales in .trivyignore need ongoing review; presence of a rationale is not acceptance evidence for every future build.

Ephemeral-container mutation, verifier outages, isolated wrong-signer/wrong-source experiments, complete incident response, and recovery exercises need additional evidence. These are limitations of the described project. The website preserves them rather than adding infrastructure features to make a stronger story.

Source anchors

Historical decision notes, handoff and deferred work, legacy Ratify ADR, and disabled compatibility resources.