The recorded runtime test deliberately executes /bin/sh -c 'id' inside an application Pod. The shell returns the non-root user identity. A subsequent query finds a Critical Falco event naming the custom shell rule. This demonstrates detection after execution, which is the correct claim for a runtime observation control.
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.
The application image uses UID/GID 10001. Helm requests non-root execution, a read-only root filesystem, no privilege escalation, dropped capabilities, and RuntimeDefault seccomp. Those limits reduce privilege but do not remove all shell binaries from a slim Python image.
The production Falco rule checks spawned_process and container, matches process names in shell_binaries, and excludes kube-system and falco-system. It emits Critical output with workload and command context. The Falco module configures rule matching as all, addressing the possibility that a broader earlier rule would suppress the custom rule’s event.
Expected behavior for the controlled test is an event when the shell is spawned. A rule named “Shell Spawned In Signed Workload Pod” does not make a cryptographic claim: its condition does not inspect a signature, signing identity, or attestation.
It then reads fresh Falco logs, filters the named rule, and displays a JSON object with priority, rule and output. The event includes the application namespace and cmdline=sh -c id.
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.
This is not a denied exec, a prevented shell, or a terminated workload. It is a successful process invocation followed by observed detection. The user identity is useful supporting evidence for non-root execution in that test; it does not prove all possible workload behavior was constrained.
The event contains image-repository and image-tag metadata, but the screenshot does not establish a manifest digest or full build commit for that process. The catalogue leaves its revision unknown. The baseline Helm digest and other acceptance capture are related historical context, not proof that substituting their metadata reconstructs this event’s exact artifact identity.
A fresh reproduction should preserve the selected GitOps digest, Pod specification image reference, container status image ID, sensor/rule revision, command time, and event time together. That would provide a stronger association between origin checks and later behavior without treating a tag as an immutable identity.
The production root can optionally create Pub/Sub, a Cloud Function, workload-identity grants, and Discord routing. The validation README explicitly says that path was disabled until a real webhook was supplied, so no Discord alert was captured.
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 sensor event, a published message, a delivered notification, and an operator’s response are separate outcomes. The capture establishes the first. This task does not claim the others, nor a tested recovery or automatic incident action.
The useful evidence includes the event’s command, namespace, workload identity, selected digest, surrounding process activity, operator/audit context where available, and the sensor configuration. Correlating those records is conceptual operational guidance added by the handbook. It is not an executed incident-response test.
