Detect and prevent privilege escalation in Kubernetes pods by monitoring security contexts, capabilities, and syscall patterns with Falco and OPA policies.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Detect and prevent privilege escalation in Kubernetes pods by monitoring security contexts, capabilities, and syscall patterns with Falco and OPA policies.
Privilege escalation in Kubernetes occurs when a pod or container gains elevated permissions beyond its intended scope. This includes running as root, using privileged mode, mounting host filesystems, enabling dangerous Linux capabilities, or exploiting kernel vulnerabilities. Detection combines admission control (prevention), runtime monitoring (detection), and audit logging (investigation).
When to Use
When investigating security incidents that require detecting privilege escalation in kubernetes pods
When building detection rules or threat hunting queries for this domain
When SOC analysts need structured procedures for this analysis type
When validating security monitoring coverage for related attack techniques
Detection Gaps & Validation
PSA in audit/warn mode does not block: only pod-security.kubernetes.io/enforce rejects pods. A namespace labelled audit=restricted/warn=restricted without enforce lets a privileged: true pod schedule - the violation is merely logged.
Gatekeeper constraint in dryrun: the K8sDangerousPriv template enforces nothing while enforcementAction: dryrun; check kubectl get constraints -o json | jq '.items[].spec.enforcementAction'.
runAsUser: 0 via the image, not the spec: a container whose Dockerfile USER root runs as root even when securityContext.runAsUser is unset, so spec-only jq checks for runAsUser == 0 miss it - verify at runtime with kubectl exec -- id.
allowPrivilegeEscalation defaults to true when omitted; absence of the field is itself a finding.
Falco capset rule is noisy and easy to mute; the dangerous capabilities runtime rule depends on container.cap_effective, which can be empty under some runtimes.
automountServiceAccountToken left enabled allows token theft → API escalation that no securityContext rule catches.
How to validate:kubectl apply a pod with and into the target namespace and confirm it is at admission (PSA/Gatekeeper) that Falco emits the privilege-escalation alert if it does run.
