Observe behavior after admission
Admission evaluates claims about an image before accepting a workload request. Once the program runs, it can receive inputs, encounter vulnerabilities, or be accessed by an operator. A correctly admitted artifact can therefore produce behavior the release process did not anticipate. Runtime observation addresses that different question.
- 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 process event this rule sees
Section titled “The process event this rule sees”The production Falco configuration defines Shell Spawned In Signed Workload Pod. Its actual condition is a spawned process in a container whose process name belongs to shell_binaries, excluding kube-system and falco-system. Output includes user, Pod, namespace, container, image repository, and command line, with CRITICAL priority.
The title reflects the intended deployment story. The rule does not look up a Cosign signature, check the selected digest, or confirm a prior admission decision. It can detect a matching shell in an unsigned workload outside admission’s image scope. Conversely, malicious behavior without a matching shell event may be outside this rule. Use the condition to understand the guarantee instead of deriving it from the rule name.
The Falco module installs the chart with the configured eBPF driver, Kubernetes metadata collection, custom rules, and rule_matching: all. The historical notes explain that first-match processing allowed a broad default rule to prevent this custom rule from being evaluated for the same event. The stored setting ensures all matching rules can produce their observations; it does not make detection exhaustive.
Detection was observed, prevention was not
Section titled “Detection was observed, prevention was not”The owner validation record reports a controlled kubectl exec shell with sh -c id and a CRITICAL custom-rule event. The shell command executed. The evidence therefore supports detection, not blocking or automatic containment.
The final image contains a slim distribution runtime and the controlled test demonstrates shell availability. Hardening removes the build-stage compiler and constrains privileges/filesystem behavior; it is inaccurate to say the runtime has no interactive shell. Non-root execution, read-only filesystem, seccomp, and dropped capabilities reduce avenues of harm, but still permit the tested process behavior.
The sample application’s /info is not a verifier. Its source returns signed: true as a constant and defaults IMAGE_DIGEST to unknown. The historical Helm template does not inject that variable. Use registry verification and Kubernetes image selection, not that self-reported boolean, as artifact evidence.
Optional alert routing
Section titled “Optional alert routing”The module enables Falcosidekick, but the alerting resources are conditional on enable_runtime_alerting, whose default is false. When deliberately enabled, the defined path is Falco → Falcosidekick → Pub/Sub → Cloud Function → Discord. Falcosidekick uses a Kubernetes ServiceAccount bound to a topic-level publisher GSA; the Discord URL flows to Secret Manager through the alerting module.
The record explicitly says no Discord alert was captured because that path was disabled. Installed sidekick replicas do not prove external delivery. Enabling the code later would require a real owned destination, appropriate secret handling, and a delivery test; it cannot be inferred from the Terraform definition or the local shell event.
Response remains a separate decision
Section titled “Response remains a separate decision”A CRITICAL record should prompt investigation of the process, identity, selected artifact, and relevant deployment changes. This baseline does not attach an automated kill/quarantine action to the rule. Guidance for response in cleanup and response distinguishes source-backed historical operations from added, untested operational reasoning.
Read the controlled runtime evidence for the particular observation and its limits. The release journey ends with an admitted artifact, but the security responsibilities continue through observation, interpretation, and deliberate response.