Admission scope, exceptions, and availability
“ClusterPolicy” is a resource type, not evidence that every image in the cluster is verified. The baseline policy matches Pod requests in selected namespaces and verifies images under one registry path. Those qualifications determine its actual security boundary.
Exact namespace and image scope
Section titled “Exact namespace and image scope”Each of the three verification rules excludes namespaces whose kubernetes.io/metadata.name is kube-system, kyverno, argocd, crossplane-system, or cert-manager. The image reference pattern is the historical project’s europe-west1-docker.pkg.dev/.../supply-chain-security/* repository path. The explicit full path remains in the pinned implementation source.
Within that scope, the policy requires an approved keyless image signature, authenticated SPDX attestation, and authenticated SLSA v0.2 provenance satisfying builder, entrypoint, and source URI conditions. It configures mutateDigest: false, verifyDigest: true, and required: true in all three rules.
Images from unmatched registry paths are not covered by these verification entries. Excluded namespaces are not covered by these rules. There is no separate blanket rule in this file rejecting every image outside the application repository. A secure description therefore says “matching application images outside the listed exclusions”, not “all cluster workloads must be signed”.
Tested container fields
Section titled “Tested container fields”- The trusted acceptance capture establishes the signed regular-container path in its setup.
- The unsigned-init fixture targets initContainers before application startup.
- The mixed fixture combines signed application and unsigned init; it is not an unsigned regular sidecar experiment.
- Ephemeral container subresource coverage remains unverified by these captures/tests.
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 baseline includes a signed regular-container fixture and two mixed-image fixtures. Both mixed fixtures contain a signed regular container plus an unsigned initContainer from the matching registry. The historical screenshot shows denial for both API-server dry-run requests.
This is strong evidence against that specific initContainer bypass. It is not separate proof for an unsigned regular sidecar beside a signed main container. No recorded ephemeral-container subresource test was found. Policy text and product capabilities are not substitutes for a tested installed-version path. The handbook therefore labels ephemeral-container coverage as unverified rather than inferring it from the policy title.
Enforce is not a complete outage contract
Section titled “Enforce is not a complete outage contract”validationFailureAction: Enforce expresses rejection when a matching policy validation fails. A capture shows a webhook named mutate.kyverno.svc-fail denying the unsigned request. Neither detail alone specifies the complete API-server behavior when the admission controller is unreachable, times out, cannot authenticate to the registry, or cannot retrieve transparency data.
The committed Kyverno values file configures maximum context size and a Workload Identity annotation. It does not pin a Kyverno chart/controller version or include the installed webhook configuration. This review cannot therefore establish a version-specific default failure policy. No controller-outage or registry-outage experiment is claimed. Reproduction must inspect the effective webhook failurePolicy, timeout, namespace/object selection, controller version and policy error behavior before declaring a tested fail-closed availability contract.
A denial on an unsigned image demonstrates working rejection, while an outage tests whether necessary decisions remain available. Treating those as the same experiment would hide an operational trade-off: failing closed can prevent an unsafe request and can also block recovery or legitimate deployment during a verifier incident.
Background reports do not evict running Pods
Section titled “Background reports do not evict running Pods”The policy sets background: true. That configuration should not be read as automatic removal of already running workloads. Background policy reporting and admission decisions are different execution paths. The supplied evidence does not demonstrate retroactive eviction, continuous cryptographic revalidation, or automatic termination after metadata disappears.
The repository preserves earlier Gatekeeper/Ratify configurations and historical evidence. Their namespace lists, identity trade-offs, and webhook behavior must not be silently assigned to the active Kyverno acceptance path. The GCP edition explains the source and captures that actually support each claim.
Residual decisions
Section titled “Residual decisions”Namespace exclusions can reduce conflicts with system controllers, while leaving privileged infrastructure outside this artifact-origin contract. A narrower registry scope limits operational impact, while leaving unmatched image sources unverified by these entries. Availability behavior can favor rejection during uncertainty, while making controller recovery harder. These are design responsibilities to examine explicitly, not bypass instructions.
See container-field evidence for what the negative tests actually changed and known gaps for the untested requests and outages.
