Kubernetes and Container Runtime Security: Hardening Clusters From Image Build to eBPF Runtime
Default Kubernetes configurations optimize for developer velocity, not isolation. A compromised pod in an unhardened cluster is often one token read away from taking over the underlying cloud account.
Kubernetes is the operating system of modern enterprise cloud infrastructure, and by default it is remarkably trusting. Out of the box, every pod in a cluster can talk to every other pod across namespaces, service account tokens are automatically mounted into containers, and workloads frequently run as root with full Linux capabilities. When an attacker exploits an application vulnerability inside a single pod, an unhardened cluster hands them a lateral movement highway.
The Four Layers of Kubernetes Defense-in-Depth
| Lifecycle Layer | Key Attack Vector | Mandatory Hardening Controls |
|---|---|---|
| 1. Build & Registry | Typosquatted base images, embedded secrets, unpatched OS packages | Minimal/distroless base images, Cosign image signing, SBOM generation, registry admission blocking |
| 2. Admission & Spec | Privileged containers, hostPath mounts, root execution | Pod Security Admission (restricted profile) + Kyverno/OPA Gatekeeper policy-as-code |
| 3. Cluster & Network | Pod-to-pod lateral movement, IMDS credential theft, RBAC escalation | Default-deny Cilium/Calico NetworkPolicies, disable automountServiceAccountToken, least-privilege RBAC |
| 4. Runtime (Kernel) | Container breakout, crypto-mining, reverse shells, unexpected child processes | Read-only root filesystems, Seccomp/AppArmor profiles, eBPF runtime detection (Falco/Tetragon) |
Hardening the Pod Specification: Non-Negotiable Baselines
Every production workload should pass an automated admission controller gate before the Kubernetes API server schedules it. At minimum, enforce:
runAsNonRoot: trueand an explicit high UID (runAsUser: 10001) so container processes never map to host root.readOnlyRootFilesystem: truewith ephemeralemptyDirmounts only where temporary scratch space is required—preventing attackers from downloading toolkits onto the container filesystem.allowPrivilegeEscalation: falseand dropping all Linux capabilities (drop: ["ALL"]), adding back only specific capabilities if strictly required.automountServiceAccountToken: falseon every pod that does not explicitly query the Kubernetes API server.
Eliminating Node-Level Cloud IAM Inheritance
Never attach broad cloud IAM permissions to the worker node instance profile. If any pod on that node is compromised and reaches the cloud metadata endpoint (169.254.169.254), it inherits every permission of the node. Enforce IMDSv2 with a hop limit of 1, block metadata IP ranges via CNI network policies, and bind cloud permissions directly to individual Kubernetes ServiceAccounts using OIDC Workload Identity.
eBPF Runtime Security: Watching the Kernel
Even with distroless images and read-only filesystems, memory-resident exploits and abused application credentials happen. eBPF-based security agents hook into Linux kernel tracepoints to detect anomalous behavior in real time—such as a Node.js or Java process suddenly spawning /bin/sh, reading /var/run/secrets/kubernetes.io/serviceaccount/token, or opening an outbound connection to an unknown external IP.
Harden Your Kubernetes Estates Without Slowing Deployments
We audit and harden EKS, AKS, GKE, and OpenShift clusters—implementing admission guardrails, zero-trust CNI networking, and eBPF runtime detection.
Kinematic Digital designs and operates enterprise cybersecurity programmes, from cloud posture and identity hardening to offensive validation. Explore our cybersecurity services and preemptive cybersecurity programme, or schedule an executive security briefing.
Frequently Asked Questions
What are the biggest Kubernetes security risks in production?
Over-permissive RBAC roles (such as cluster-admin bound to default service accounts), containers running as root with privileged flags, flat pod-to-pod network topologies with no NetworkPolicies, exposed Kubernetes API servers, and unpatched base container images.
What replaced PodSecurityPolicy in Kubernetes?
Pod Security Admission (PSA), built into Kubernetes since v1.25, enforces the Pod Security Standards (Privileged, Baseline, and Restricted) natively at the namespace level, often paired with Kyverno or OPA Gatekeeper for custom admission policies.
Why is container runtime security necessary if we scan images in CI/CD?
Image scanning in CI/CD only catches known CVEs at build time. It cannot detect zero-day exploits, compromised application dependencies triggered at runtime, credential theft via the kubelet API, or interactive shell execution inside a running pod.
How does eBPF improve Kubernetes runtime security?
eBPF (Extended Berkeley Packet Filter) runs sandboxed observability and security programs directly in the Linux kernel without loading fragile kernel modules. It provides low-overhead visibility into every system call, file access, and network connection per pod and namespace.
Should pods be allowed to reach cloud instance metadata services?
No, unless explicitly required and scoped. Block pod access to 169.254.169.254 via Kubernetes NetworkPolicies, enforce IMDSv2 with hop limit 1 on nodes, and use workload identity federation (AWS IRSA / Pod Identity, Azure Workload Identity, GKE Workload Identity) instead.