Kubernetes Security Hardening in 2025: Pod Security Admission, RuntimeClass and eBPF Detection

Cloud Security

PodSecurityPolicy is gone. Pod Security Admission is here but misconfigured in most clusters. This guide covers the three controls that meaningfully reduce Kubernetes attack surface in 2025: PSA enforcement modes, RuntimeClass-based workload isolation, and eBPF-powered runtime detection.

By Arjun Raghavan, Security & Systems Lead, BIPI · September 3, 2025 · 12 min read

Kubernetes 1.25 removed PodSecurityPolicy. The replacement — Pod Security Admission — shipped stable in 1.23 and became the default security gate in every cluster by 2024. Two years on, the majority of production clusters still run PSA in warn or audit mode, not enforce mode. That means the controls exist in name only. A malicious pod with hostPID or privileged flags will still schedule.

The hardening landscape in 2025 has three layers that actually reduce attack surface: Pod Security Admission enforcement, RuntimeClass-based workload isolation using gVisor or Kata Containers, and eBPF-based runtime detection using tools like Falco or Tetragon. Each layer compensates for gaps in the others. Together they create a defense-in-depth posture that makes container escape and lateral movement significantly harder.

Running PSA in warn mode is like installing a smoke detector and removing the battery. You get the logs without the protection.

Layer 1 — Pod Security Admission enforcement modes

PSA operates at the namespace level with three profiles — privileged, baseline, and restricted — and three modes — enforce, audit, and warn. Enforce mode rejects non-compliant pods at admission. Audit mode logs violations to the audit log but lets the pod schedule. Warn mode sends an API response warning to the caller.

The recommended posture for production workloads is to label every namespace with pod-security.kubernetes.io/enforce: restricted and use exemptions sparingly. Start by setting audit and warn modes org-wide, collect the violations for two weeks, work with application teams to remediate, then flip enforce. Teams that skip the audit phase find they have broken CI/CD pipelines because their build agents were running as root.

• Restricted profile blocks: hostNetwork, hostPID, hostIPC, privileged, allowPrivilegeEscalation, non-root containers.
• Use the admission webhook events in your SIEM to track which namespaces have outstanding violations.
• Annotate system namespaces like kube-system as privileged-exempt but audit them separately.
• Run kube-bench quarterly to validate PSA is in enforce mode across all new namespaces.

Layer 2 — RuntimeClass for workload isolation

RuntimeClass lets you assign a container runtime to a pod. The default is runc, which shares the host kernel. For sensitive workloads — payment processing, secret management, multi-tenant SaaS — switching the RuntimeClass to gVisor (runsc) or Kata Containers provides kernel isolation. A container escape that works against runc will fail against gVisor because the exploit targets kernel syscalls that gVisor intercepts.

The operational cost is real. gVisor adds latency for syscall-heavy workloads. Kata Containers spin up a lightweight VM per pod, adding startup time. The right approach is not to use strong isolation everywhere but to define a tier model: standard (runc plus PSA restricted), enhanced (gVisor), and isolated (Kata). Assign tiers based on data classification and blast radius.

Layer 3 — eBPF-based runtime detection

eBPF programs can attach to kernel system calls and monitor every process, file operation, and network connection inside a container without modifying the container image or injecting a sidecar. Falco uses eBPF to implement policy rules that alert on unexpected process execution inside containers. Tetragon, from Isovalent, goes further by allowing policy enforcement — killing a process in-kernel before it completes the syscall.

• Falco rule: alert on shell spawn inside a web server container.
• Falco rule: alert on unexpected outbound connection from a payment service container.
• Tetragon TracingPolicy: kill any process attempting to mount a host path or access the container runtime socket.
• Tetragon TracingPolicy: block ptrace() calls from non-debugger processes.

Cluster-level controls that complement PSA and eBPF

Network policies are often treated as optional. They are not. A default-deny ingress and egress policy on every namespace limits what a compromised pod can reach. Combine with service mesh mTLS so east-west traffic is encrypted and authenticated even inside the cluster.

RBAC auditing is the other consistently underinvested area. Run kubectl-who-can or rakkess regularly to audit who can exec into pods, get secrets, and create pods in privileged namespaces. Cluster-admin bindings should be enumerable on one hand.

Audit checklist for 2025

1. PSA enforce mode on all non-system namespaces — verify with kubectl get ns --show-labels.
2. RuntimeClass defined for sensitive workload tiers and referenced in pod specs.
3. Falco or Tetragon deployed as a DaemonSet with policies covering shell spawn, unexpected exec, and host mount attempts.
4. Network policy default-deny in every application namespace.
5. RBAC: zero ClusterRoleBindings to cluster-admin except break-glass accounts.
6. CIS Kubernetes Benchmark score above 90 percent on kube-bench output.

Closing

The tooling to harden Kubernetes properly is more mature in 2025 than it has ever been. The problem is not capability — it is configuration discipline. PSA in audit mode, RuntimeClass defined but not used, Falco deployed with no custom rules. Walk every cluster through the checklist above and treat any cluster missing enforce-mode PSA as a P1 remediation item before the next security review.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.