Kubernetes defaults are optimized for usability, not security. A default K8s cluster is a playground for attackers. This deep dive covers the entire spectrum of Kubernetes security: from hard-hitting RBAC audits and Admission Controllers to runtime defense using eBPF and Cilium.
01The Attack Chain
A typical Kubernetes compromise follows a predictable path: 1. **Initial Access**: Exposed Dashboard, Kubelet API, or vulnerable application. 2. **Execution**: RCE in a pod. 3. **Privilege Escalation**: Breaking out of the container to the host node (privileged pods). 4. **Discovery**: querying the K8s API server for secrets. 5. **Lateral Movement**: Persistence via DaemonSets or moving to other nodes.
02Policy-as-Code: OPA Gatekeeper
Don't rely on developers to remember security settings. Enforce them. Open Policy Agent (OPA) allows you to write Rego policies that reject insecure deployments. For example, blocking any pod that requests root privileges or mounts the host filesystem.
package k8srequiredlabels
violation[{"msg": msg}] {
input.review.object.kind == "Pod"
container := input.review.object.spec.containers[_]
not container.securityContext.runAsNonRoot
msg := sprintf("Container %v must run as non-root", [container.name])
}03The Power of eBPF
Traditional sidecar proxies (like Istio/Envoy) add latency. Modern security leverages eBPF (Extended Berkeley Packet Filter) to run sandboxed monitoring capabilities directly in the Linux Kernel. Tools like Tetragon and Falco use eBPF to detect suspicious syscalls (e.g., a web server spawning a shell) and kill the process instantly, offering true runtime defense.
- 01Tetragon: Process execution monitoring
- 02Cilium: L3/L4/L7 Network Policies
- 03Falco: Behavioral anomalies
