Kubernetes Security Hardening: CIS Benchmarks, Pod Security Standards, and Runtime Protection

A default Kubernetes cluster is not secure. Pods run as root. Network traffic flows unrestricted between namespaces. Secrets are stored unencrypted in etcd. Service accounts mount tokens into every pod. For regulated environments — where NIS2, DORA, or SOC 2 apply — this is unacceptable. Here's how to harden Kubernetes systematically.

CIS Kubernetes Benchmark

The CIS Kubernetes Benchmark provides 200+ specific configuration checks across: control plane components (API server, controller manager, scheduler, etcd), worker nodes (kubelet, proxy), policies (RBAC, pod security, network), and managed services (EKS, AKS, GKE each have their own benchmark).

Run kube-bench against your cluster to assess compliance. Focus on critical findings first: anonymous authentication enabled, insecure ports exposed, RBAC not enforced, audit logging disabled. Managed Kubernetes (EKS, AKS, GKE, OpenShift) handles most control plane hardening, but worker node and policy configurations are your responsibility.

Pod Security Standards

Kubernetes Pod Security Standards define three profiles:

• Privileged — No restrictions. Only for system-level workloads that need host access.
• Baseline — Prevents known privilege escalations. Blocks hostNetwork, hostPID, privileged containers.
• Restricted — Maximum hardening. Requires non-root, drops all capabilities, read-only root filesystem, no privilege escalation.

Apply Restricted by default. Use Baseline for monitoring/logging agents that need some host access. Use Privileged only for GPU device plugins and system DaemonSets. Enforce via Pod Security Admission (built into Kubernetes 1.25+) or OPA Gatekeeper for more granular control.

Network Policies

Default-deny all traffic in every namespace. Then explicitly allow required connections:

• Ingress: Allow traffic from ingress controller to application pods
• Egress: Allow DNS (kube-dns), required external APIs, and specific service-to-service connections
• Monitoring: Allow Prometheus scraping from monitoring namespace

Use Cilium for L7-aware network policies. Block egress to the metadata service (169.254.169.254) except from explicitly approved pods — this prevents SSRF attacks from accessing cloud credentials.

Admission Control

Admission controllers are your last line of defense before workloads hit the cluster:

• OPA Gatekeeper / Kyverno — Enforce custom policies: require resource limits, block latest tags, enforce labels, restrict image registries
• Image policy — Only allow images from trusted registries. Verify signatures (cosign/sigstore). Block images with critical CVEs.
• Resource quotas — Prevent namespace sprawl and resource exhaustion
• Limit ranges — Set default and maximum resource requests/limits per container

Runtime Security

Prevention fails. You need runtime detection:

• Falco — Syscall-based threat detection. Detects: shell spawned in container, unexpected network connections, file access in sensitive paths, privilege escalation attempts.
• Seccomp profiles — Restrict which syscalls containers can make. Use the RuntimeDefault profile as baseline, custom profiles for tighter restrictions.
• AppArmor/SELinux — Mandatory access control at the OS level. Restricts file access, network capabilities, and process execution.

Audit Logging

Enable Kubernetes audit logging with a comprehensive policy. Log all: authentication events, RBAC changes, secret access, namespace creation/deletion, and deployment modifications. Forward audit logs to your SIEM. NIS2 and DORA both require audit trails for security events.

What Open Empower Delivers

We harden Kubernetes clusters to CIS benchmark standards with pod security, network policies, admission control, and runtime protection. Security that's built into the platform, not bolted on after deployment.