The claim is deliberately narrow: the historical API-server path accepted the selected trusted workload and rejected a matching image lacking signatures and attestations. The positive and negative observations make the contract easier to assess than either alone, while leaving exact policy revision and today’s status unverified.
Allow and deny within the policy scopeEnforce mode applies to matched images and namespaces; outage failurePolicy is a separate operational question.
Unmatched image registries or excluded namespaces do not gain protection from this policy.
Matching Pod images must be digest pinned and have required signature and attestations.
Configured issuer, subject and selected provenance fields must satisfy the policy.
A trust mismatch denies a matching request; success permits admission, not permanent safety.
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 positive capture pipes the baseline Helm rendering into kubectl apply --dry-run=server -f -. The application chart constructs an immutable reference using image.repository@image.digest. The policy requires the approved workflow signature, SPDX attestation, and SLSA v0.2 provenance for matching application images in the selected namespace.
Expected behavior is acceptance of the signed selected digest. The capture shows both Service and Deployment configured under server dry run. It then separately reads the live Deployment, its Pods, and the selected image reference, showing two available replicas and digest 32a90d….
recorded-live-validation · accepted
The captured trusted Helm release passed API-server dry run; the application separately had two available replicas.
Expected in this setup: A workload using the signed selected digest is accepted in the matched namespace.
Recorded result: Service and Deployment configured under server dry run; live Deployment listed 2/2 ready and available.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
The signed release passes server dry-run; a separate query reports two available replicas. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
service/supply-chain-demo configured (server dry run)
deployment.apps/supply-chain-demo configured (server dry run)
RESULT: PASS - trusted workload admitted by API server / Kyverno
NAME READY UP-TO-DATE AVAILABLE AGE
supply-chain-demo 2/2 2 2 5h14m
TRUSTED IMAGE DIGEST
sha256:32a90d832fdf76794fa5477e42e1fdcec28c9eb6e0deee48ad466d1f7d9fc563
What this does not establish
Server dry run does not itself create the observed live replicas; the capture includes separate live-read commands.
The source commit that built this image and the exact installed policy revision are not established by this screenshot.
Acceptance is historical, not proof of today's controller or workload status.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. The original screenshot is approved for display at the owner’s explicit request for all evidence images and subsequent Cloudflare publication. Original terminal metadata remains visible. No additional pixel redaction was selected or applied. The selected transcript omits incidental prompts without changing the recorded result.
The dry-run messages do not create those replicas. They establish acceptance of the submitted request at capture time; the live reads establish a separately observed running application. The screenshot does not independently identify the exact installed policy commit or the original source commit that built the accepted image.
The validation README identifies an actual GAR unsigned-test image with digest 18549c…. The negative capture submits an unsigned Pod through server dry run. Because its image lies within the verification pattern and its namespace is covered, expected behavior is rejection for missing authenticated claims.
recorded-live-validation · rejected
The captured API-server dry run rejected a matching unsigned image.
Expected in this setup: Reject the matched image without required approved signature and attestations.
Recorded result: mutate.kyverno.svc-fail denied the request; signature reported no signatures found and attestations reported no matching attestations.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
API-server dry-run rejects the matched unsigned test image. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
Unsigned image digest:
sha256:18549c45e5d1d87804372cb8082cefbee1019b9c592d816d14817cc12472ca17
admission webhook "mutate.kyverno.svc-fail" denied the request
resource Pod/default/unsigned-image-test was blocked
verify-image-signature: no signatures found
verify-provenance-attestation: image attestations verification failed, verifiedCount: 0, requiredCount: 1, error: no matching attestations
verify-sbom-attestation: image attestations verification failed, verifiedCount: 0, requiredCount: 1, error: no matching attestations
RESULT: PASS - unsigned image DENIED; no signatures found
What this does not establish
This is one server-side dry-run request, not a persisted negative deployment.
Three missing claims occur together; it does not isolate each attestation requirement independently.
Unmatched registries and excluded namespaces were not tested in this capture.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. The original screenshot is approved for display at the owner’s explicit request for all evidence images and subsequent Cloudflare publication. Original terminal metadata remains visible. No additional pixel redaction was selected or applied. The selected transcript omits incidental prompts without changing the recorded result.
The webhook denial names the Pod and all three baseline rules. The signature rule reports “no signatures found”; the two attestation rules report no matching attestations with zero verified against a required count of one. This supports the missing-claim rejection for that request. It is not evidence that a standalone signature without an SBOM was separately tested, because all three required claims are absent together.
The approved Argo capture shows the application Healthy and Synced, with two running Pod nodes in its resource tree. It visibly distinguishes current sync main(c67aefd) from last successful sync 9bf574c. Those are GitOps source observations, not image build identities.
recorded-live-validation · accepted
The pictured application was Healthy and Synced to canonical main at capture time.
Expected in this setup: Argo reconciles the selected Helm release and reports healthy workload resources.
Recorded result: Capture shows Healthy, Synced to main(c67aefd), Sync OK to 9bf574c, two running Pod nodes.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision c67aefd
Argo reconciliation captured on 2026-08-23; current sync c67aefd and last-sync 9bf574c are separate observations. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible labels:
APP HEALTH Healthy
SYNC STATUS Synced to main(c67aefd)
Auto sync is enabled.
LAST SYNC Sync OK to 9bf574c
Succeeded 5 hours ago (Sun Aug 23 2026 14:56:28 GMT+0530)
Two Pod nodes: Running 1/1
What this does not establish
Healthy/Synced describes captured reconciliation, not cryptographic verification by Argo.
Current sync revision and last-sync revision are different visible fields; neither is automatically the artifact build revision.
The picture does not independently establish policy revision or all admitted image fields.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. Unmodified original. Application status, public source revisions and timestamps retained; no user-info contents or credential visible.
Argo’s status demonstrates historical reconciliation and resource health. It does not verify signatures itself. The admission policy provides the cryptographic decision for matching requests; Argo is the reconciler that attempts to make the reviewed Git state real.
The policy’s exact registry pattern and namespace exclusions matter. These captures do not establish rejection of every registry or every namespace. They do not test a controller outage, metadata outage, unavailable Rekor service, or a later change to claims. They also do not show automatic eviction of an already running workload.
The records are reviewed historical evidence dated from the collection’s 2026-08-23 context. This implementation task did not connect to GCP or rerun the admission experiment. A new owned reproduction should capture rendered input, exact policy/controller versions, full image digest, expected identity, API response, and relevant GitOps revision together.
