Maintained and documented by Satyam Agnihotri · Content reviewed
Admission permits an artifact to start under a policy. The application then receives requests, reads data, executes code, and can encounter vulnerabilities or unexpected operator actions. No signature can predict every behavior of those bytes in every environment. That is the gap between authenticated origin and acceptable runtime behavior.
This baseline treats that gap with container hardening and Falco observation. They serve different responsibilities from cryptographic admission, and their demonstrated outcomes should be reported separately.
The gap after admissionFalco shell detection is observation. Optional external alerting is disabled by default and delivery is unverified.
A correctly admitted image can later execute undesirable behavior.
Modern eBPF exposes process/container events to the running Falco sensor.
The custom rule selects shell process events in containers outside kube-system and falco-system; its name does not establish cryptographic signature checks.
Falcosidekick receives events; optional Pub/Sub/function routing needs explicit enablement and separate delivery evidence.
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.
PR and final-image scans may stop a workflow when configured blocking findings exceed its threshold after ignored findings are applied. Kyverno can deny an admission request for a matching image missing the required claims or failing the expected identity/provenance contract. Prevention changes whether an action proceeds at that boundary.
A successful scan is not proof of no vulnerabilities. A successful admission decision establishes the configured origin contract for the images and namespaces it matches. Neither check inspects every later request or process execution.
The Dockerfile creates numeric UID/GID 10001 and runs the application as that user. The Helm template and values request non-root execution, disallow privilege escalation, use a read-only root filesystem, drop all Linux capabilities, and choose the RuntimeDefault seccomp profile. The final image excludes the builder’s compiler and removes pip/setuptools from the copied virtual environment.
These settings reduce privilege and writable surfaces. They are not a demonstration that exploit impact is zero. The slim Python runtime still has a shell; the historical test successfully invokes /bin/sh -c 'id'. Setting the account’s login shell to nologin does not remove /bin/sh from the image or prevent an authorized exec call from launching it.
The custom Falco rule matches spawned container processes whose name is in shell_binaries, outside kube-system and falco-system. It emits a Critical event with process, workload, namespace, and image-repository context. Its title, “Shell Spawned In Signed Workload Pod”, is an operator-facing description. The condition does not retrieve signatures, validate a digest, or check a cryptographic admission record.
The runtime namespace scope is different from Kyverno’s. Several namespaces excluded from admission are not excluded by this shell rule. The sentence “every workload is signed” in a source comment is broader than the actual admission policy. The handbook follows the condition and policy match rather than adopting that comment as a verified property.
recorded-live-validation · detected
The shell executed as UID/GID 10001 and a Critical Falco event was then recorded.
Expected in this setup: Record unexpected shell execution in the application namespace with the configured Falco rule.
Recorded result: The command returned id output and Falco logs showed the named Critical shell rule.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
The controlled shell returns UID/GID 10001; Falco subsequently records a Critical shell event. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
uid=10001(appuser) gid=10001(appgroup) groups=10001(appgroup)
"priority": "Critical"
"rule": "Shell Spawned In Signed Workload Pod"
Critical Unexpected shell spawned in hardened pod
user=appuser
ns=default
cmdline=sh -c id
RESULT: PASS - Falco detected the controlled runtime shell
What this does not establish
Detection happened after successful shell execution; no prevention or automatic termination observed.
The rule condition does not verify signatures.
The captured image tag does not establish a manifest digest or build commit.
No external notification or incident-response completion captured.
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 captured test launches a shell, shows id returning UID/GID 10001, and then queries a fresh Falco event. The shell happened. Falco detected it. No blocked shell, automatic termination, or human response is recorded. A Critical label expresses severity; it does not prove someone received or acted on the event.
Terraform can optionally route Falcosidekick events to Pub/Sub and a Cloud Function that posts to Discord, with workload-identity permissions for publication and Secret Manager for the webhook. The production root enables those resources only when enable_runtime_alerting is true. The recorded validation states that no Discord alert was captured because the path was disabled pending a real webhook.
Even a delivered message would establish notification delivery rather than incident resolution. Investigation, isolating a workload, rollback, credential review, and evidence preservation require operational decisions. The source contains troubleshooting guidance; this task did not execute a recovery or incident-response exercise.
not-verified · gap
Discord delivery and incident response were not demonstrated in the recorded validation.
Expected in this setup: Only an enabled, configured and executed alert test could establish external delivery.
Recorded result: The validation README says the alerting path was disabled pending a real webhook; no Discord capture.
Historical optional GCP alerting path; disabled per validation README · observed date unknown · source revision unknown; not inferred from the documentation baseline
Transcript / inspected observation
Recorded statement: No Discord alert was captured because the alerting path is disabled until a real webhook is supplied.
What this does not establish
Optional Terraform resources do not establish enabled deployment.
A runtime log alone does not prove event delivery or response.
Source inspected against the pinned baseline; execution scope stated explicitly. No screenshot or sensitive runtime state published.
A shell event can represent exploitation, troubleshooting, a test fixture, or an authorized operator action. Its meaning depends on context. The next action is to correlate the event with the workload’s selected digest, deployment revision, caller/audit information if available, and surrounding process activity. This is conceptual response guidance, not a tested automated runbook.
The historical event’s reported image tag is not a verified image-manifest digest. This limits how strongly the screenshot alone can associate process behavior with a particular build. A new reproduction should collect Pod specification and status alongside event output, preserving timestamps and the sensor/rule configuration.
The admission decision and runtime observation are both useful because they answer different questions. Continue with the runtime evidence case for the test setup and exact interpretation limits.
