Detect and prevent privilege escalation in Kubernetes pods by monitoring security contexts, capabilities, and syscall patterns with Falco and OPA policies.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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.
