Container and Kubernetes Threats

What Makes Container Security Different

Containers share the host kernel — a container escape vulnerability compromises the entire host. Unlike VMs where each guest has its own kernel, a container breakout from any container affects all other containers on the same node.
Kubernetes adds a control plane layer (API server, etcd, kubelet) with its own authentication/authorization model (RBAC, ServiceAccounts, PodSecurity Policies) that has no equivalent in traditional infrastructure.
Traditional EDR agents often do not run inside containers. Detection requires runtime security tools (Falco, Aqua, Sysdig), Kubernetes audit logs, and container-aware threat detection.
MITRE ATT&CK maps container attacks to T1611 (Escape to Host), T1525 (Cloud Service Discovery), and T1574.002 (DLL Side-Loading / image hijack).

Container Escape

Container escape is the most severe container threat — an attacker breaks out of a container and gains access to the host operating system.

Escape Methods

Method	How It Works	Vulnerability Class
Kernel vulnerability	Exploit a kernel CVE (Dirty Pipe CVE-2022-0847, Dirty COW CVE-2016-5195) to escape the container’s namespace isolation	Kernel exploit
Capability abuse	Container with `CAP_SYS_ADMIN` or `SYS_PTRACE` can mount the host filesystem or attach to host processes	Misconfiguration
Mount propagation	Container mounts a host path with `mount propagation: bidirectional` — changes in the container propagate to the host	Misconfiguration
`--privileged` container	A privileged container has all capabilities and can directly manipulate the host kernel	Misconfiguration
cgroup escape	Container with cgroup v1 access can write to `release_agent` to trigger host-side execution	Misconfiguration or CVE
Container runtime CVE	Exploit in runc (CVE-2019-5736), containerd, or Docker (CVE-2018-15664)	Runtime exploit

Detecting Privileged Containers

Kubernetes — find privileged pods:

# List all privileged containers in the cluster
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace} {.metadata.name} {.spec.containers[].securityContext.privileged}{"\n"}{end}' | grep true

Detection — Falco rule for privileged container:

- rule: Container with SYS_ADMIN Capability
  desc: Detect containers running with CAP_SYS_ADMIN (potential escape vector)
  condition: container and evt.type=clone and container.capabilities contains "SYS_ADMIN"
  output: "CAP_SYS_ADMIN container started (user=%user.name container=%container.id image=%container.image.repository)"
  priority: HIGH
  tags: [container, escape, misconfiguration]

Detection — Container Escape via Mount Namespace

SPL query — detect host filesystem mounts from unknown containers:

index=kubernetes sourcetype=kube_audit
| search verb=CREATE resource=pod
| select requestObject.spec.containers[].volumeMounts[].mountPath
| where requestObject.spec.containers[].volumeMounts[].mountPath = "/host" OR requestObject.spec.containers[].volumeMounts[].mountPath = "/var/run/docker.sock"
| eval alert = "Container mounting host filesystem — possible escape preparation"
| table _time, user.username, requestObject.metadata.name, requestObject.spec.containers[].volumeMounts, alert

Kubernetes RBAC Abuse

Kubernetes RBAC is the primary access control mechanism but is frequently misconfigured — granting more permissions than necessary.

Dangerous RBAC Permissions

Permission	What It Allows	Risk Level
`cluster-admin` (ClusterRoleBinding)	Full admin access to the entire cluster	Critical — should never be granted to a user or pod
`*` on all resources	Ability to create, read, update, delete any resource	Critical
`create pods/exec`	Ability to execute commands in any pod	Critical — equivalent to root on every pod
`get secrets` (across all namespaces)	Read all secrets including service account tokens	Critical
`create deployments` + `delete deployments`	Ability to create/deploy arbitrary workloads	High
`list pods`	Enumeration of all running pods	Medium — reconnaissance
`get nodes`	Information gathering about cluster nodes	Medium
`get events`	Read cluster events (may reveal sensitive info)	Low

Detection — Overly Permissive Roles

Kubernetes audit log — detect cluster-admin grants:

index=kubernetes sourcetype=kube_audit
| search verb=CREATE OR verb=UPDATE resource=clusterrolebindings
| where requestObject.roleRef.name = "cluster-admin"
| eval alert = "Cluster-admin binding created by " . user.username
| table _time, user.username, sourceIPs, requestObject.subjects, alert

KQL — detect pods creating other pods (RBAC abuse from compromised service account):

KubernetesAuditLogs
| where OperationName == "CREATE"
| where Resource == "pods"
| where User.Username != "system:kube-controller-manager" and User.Username != "system:node:*"
| extend PodCreator = User.Username
| summarize PodsCreated = count() by PodCreator, bin(TimeGenerated, 1h)
| where PodsCreated > 5
| project TimeGenerated, PodCreator, PodsCreated

Admission Controller Bypass

Admission controllers (PodSecurityPolicy, OPA/Gatekeeper, Kyverno) enforce security policies before pods are created. Attackers try to bypass them.

Bypass Techniques

Technique	How It Works	How to Detect
Privileged namespace	Create pods in a namespace that has lax admission policies	Audit log — pod creation in non-standard namespace with privileged fields
Mutating webhook evasion	Craft a pod spec that avoids the mutating webhook’s pattern (e.g., set `runAsUser: 0` explicitly before webhook sets it to non-root)	Compare pod spec before and after webhook mutation
CRD abuse	Create a Custom Resource that triggers a controller to create pods without passing through admission	Monitor controller create operations
Static pod creation	Place pod manifest in `/etc/kubernetes/manifests/` on a node — bypasses API server entirely	Node-level file monitoring — extremely difficult to detect centrally
Direct kubelet API access	If the kubelet read-only port (10250) is exposed, an attacker can create pods directly without API server admission control	Network monitoring — direct connections to node port 10250

Detection — Direct Kubelet API Access

index=network sourcetype=firewall_log
| search dest_port=10250 AND dest_ip=10.96.0.0/12 (kubernetes pod CIDR)
| stats count by src_ip, dest_ip, dest_port, bin(_time, 5m)
| where count > 3
| eval alert = "Direct kubelet API access from " . src_ip . " — possible admission controller bypass"
| table _time, src_ip, dest_ip, dest_port, count, alert

Pod Security Policy Evasion

Pod Security Policies (PSPs are deprecated; Pod Security Admission is the replacement) enforce constraints on pod security contexts. Attackers evade them to run privileged containers.

Common Evasion Patterns

Evasion	What the Attacker Does	Detection
`runAsUser: 0`	Explicitly set the user to root (bypasses non-root constraint)	Audit log — container with `runAsUser: 0`
`allowPrivilegeEscalation: true`	Allows the container process to gain more privileges than its parent	Pod spec in audit logs — `allowPrivilegeEscalation: true`
Host networking	Use `hostNetwork: true` to bypass network policies	Pod spec — `hostNetwork: true`
HostPID / HostIPC	Use `hostPID: true` to see all host processes	Pod spec — `hostPID: true` or `hostIPC: true`
`seccomp` disabled	Run without seccomp profile, enabling syscalls that should be filtered	Falco — syscall denied by default seccomp but executed in container

Container Supply Chain Attacks

Attackers compromise the container image supply chain by injecting malicious code into base images, registry images, or CI/CD pipelines.

Attack Vectors

Vector	Example	Detection
Malicious base image	Typosquatted image: `node` vs `n0de`, or upstream image compromise	Image hash verification, vulnerability scanning (Trivy, Grype)
Dependency confusion	Package name that exists in both public and private registries — attacker uploads a malicious version to the public registry	Lock file verification, private registry mirror configuration
Build pipeline compromise	Attacker modifies Dockerfile or CI pipeline to add malicious layer	CI/CD audit logs, artifact hash verification
Registry compromise	Attacker pushes malicious image to public or private registry	Registry audit logs, image signing (Cosign, Notary)
Sidecar injection via admission controller	Attacker modifies a mutating webhook to inject a sidecar container into every pod	Webhook configuration change audit

Detection — Image Scan Results

index=kubernetes sourcetype=image_scan
| search vulnerability_critical > 0 OR vulnerability_high > 0
| stats sum(vulnerability_critical) as critical, sum(vulnerability_high) as high by image, repository
| where critical > 0
| eval alert = "Image " . image . " has " . critical . " critical vulnerabilities"
| sort - critical
| table image, repository, critical, high, alert

Kubernetes Threat Reference Table

Threat Category	Detection Source	Key Signals	MITRE Reference
Container escape	Falco, Sysdig, host-level EDR	`CAP_SYS_ADMIN`, privileged container, mount propagation, runc CVE exploitation	T1611
RBAC abuse	Kubernetes audit logs	Cluster-admin binding, pod/exec permissions, secrets read from unusual users	T1078
Admission controller bypass	Kubernetes audit logs, webhook logs	Pod specs bypassing constraints, direct kubelet API access	T1610
Pod security policy evasion	Kubernetes audit logs, Falco	`runAsUser: 0`, `hostNetwork: true`, `allowPrivilegeEscalation`	T1610
Supply chain attack	Image scanning, Sigstore, CI/CD audit logs	Malicious image, dependency confusion, unsigned image	T1195
Service account token theft	Kubernetes audit logs, container runtime	Mounted service account token from unexpected pod, pod enumeration	T1528
K8s data plane attack	Kubernetes audit logs, network logs	Unauthorized `get secrets`, `list pods` across namespaces	T1078.004

Cloud Threats — Credential Theft, IMDS Abuse, Hijacking, Privilege Escalation — detection and response for T1525, T1552, T1613 techniques
API Attacks — OWASP API Top 10 — detection and response for T1190 techniques
Cloud Security Fundamentals — detection and response for T1525 techniques
Kill Chain — covers the kill chain concepts
Log Sources Overview — covers the log sources overview concepts