Kubernetes Security Hardening: CIS Benchmark, RBAC, and Runtime Protection
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Kubernetes clusters fail under attack in predictable ways: an exposed API server accepts anonymous requests, a service account with cluster-admin runs a compromised application, a privileged pod provides direct host access, and an unmonitored namespace runs attacker-controlled workloads for weeks. The CIS Kubernetes Benchmark exists specifically to close these gaps before an attacker finds them.
This guide covers the controls that block the highest-frequency attack paths, in the order that delivers the most risk reduction per unit of implementation effort.
API Server and etcd Hardening
The Kubernetes API server is the control plane entry point. Disable anonymous authentication with --anonymous-auth=false and restrict the API server to authorized CIDR ranges. Enable audit logging with --audit-log-path, --audit-log-maxage=30, and --audit-log-maxbackup=10 to capture all API server activity. Set --insecure-port=0 to disable unencrypted access. For etcd, enable encryption at rest with an EncryptionConfiguration manifest using AES-GCM for secrets, and restrict etcd access to the API server only via mutual TLS. Run kube-bench against your cluster to score CIS compliance: docker run --pid=host -v /etc:/etc:ro aquasec/kube-bench:latest.
RBAC Design and Least Privilege
Kubernetes RBAC is additive-only: no deny rules exist, so over-permissive bindings are the primary privilege escalation path. Audit all ClusterRoleBindings with kubectl get clusterrolebindings -o wide and remove any binding that grants cluster-admin to service accounts or non-admin users. Replace wildcard verbs (verbs: ["*"]) with explicit verb lists. Scope bindings to namespaces with RoleBindings rather than ClusterRoleBindings wherever possible. Disable automountServiceAccountToken: false on pods that do not call the Kubernetes API. Audit token mounts with kubectl get pods --all-namespaces -o json and filter on .spec.automountServiceAccountToken.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Pod Security and Admission Controllers
Pod Security Admission (PSA), stable since Kubernetes 1.25, replaces the deprecated PodSecurityPolicy. Apply the restricted profile to all namespaces that do not require elevated privileges: kubectl label namespace <ns> pod-security.kubernetes.io/enforce=restricted. The restricted profile blocks privileged containers, hostPath mounts, hostNetwork, and requires non-root execution. For policy enforcement beyond PSA, deploy OPA Gatekeeper or Kyverno. Kyverno policies are YAML-native and easier to write: a ClusterPolicy with spec.rules[].validate blocks containers with allowPrivilegeEscalation: true. Test policies in audit mode before enforcing to measure existing violations without breaking workloads.
Network Policies and Runtime Detection
Without NetworkPolicy objects, all pods in a cluster can reach all other pods. Apply default-deny ingress and egress policies to every namespace, then add explicit allow rules for required communication paths. Use a CNI plugin that enforces NetworkPolicy: Calico, Cilium, and Weave all support it; Flannel alone does not. For runtime detection, deploy Falco with the default ruleset plus custom rules for sensitive file access (/etc/shadow, /etc/kubernetes/admin.conf), shell execution inside containers, and outbound connections to non-approved CIDRs. Forward Falco alerts to your SIEM via the HTTP output plugin.
The bottom line
Kubernetes security is not a one-time configuration. Run kube-bench on every cluster upgrade, audit RBAC bindings quarterly, and review Falco alert volume weekly. The CIS Benchmark gives you the baseline; continuous monitoring keeps you on it as workloads and configurations drift. For the container image and registry layer, see the container security tools comparison. For Linux host hardening that underpins your Kubernetes nodes, see the Linux server hardening checklist.
Frequently asked questions
What is the CIS Kubernetes Benchmark and how do I score against it?
The CIS Kubernetes Benchmark is a community-developed hardening checklist for Kubernetes control plane and worker node configuration. It has two levels: Level 1 covers controls with minimal operational impact, Level 2 adds stricter controls for high-security environments. Run kube-bench (open source, from Aqua Security) against your cluster to generate a scored report: it checks API server flags, etcd configuration, kubelet settings, and RBAC policies. Target Level 1 compliance for all production clusters and Level 2 for clusters handling regulated workloads.
What is the difference between OPA Gatekeeper and Kyverno?
Both are Kubernetes admission controllers that enforce custom policies. OPA Gatekeeper uses Rego, a purpose-built policy language with strong expressiveness but a steep learning curve. Kyverno uses YAML-native policies that mirror Kubernetes resource syntax, making them easier to write and review without learning a new language. Kyverno also supports mutating policies (auto-adding security context fields) and generate rules (creating companion resources). For teams already using OPA elsewhere, Gatekeeper reuses that investment. For teams starting fresh, Kyverno has less friction.
How do I prevent container escape vulnerabilities in Kubernetes?
Container escapes require privileged access to the host kernel. Block the most common paths: set privileged: false and allowPrivilegeEscalation: false in the security context, use readOnlyRootFilesystem: true, drop all Linux capabilities with capabilities.drop: [ALL] and only add back what is required, block hostPID, hostIPC, and hostNetwork, and restrict hostPath volume mounts. Apply these controls via Pod Security Admission restricted profile or a Kyverno ClusterPolicy. Use Falco runtime detection to alert on execve syscalls within containers and unexpected file opens in /proc.
How should I handle Kubernetes secrets to prevent credential exposure?
Kubernetes Secrets are base64-encoded by default, not encrypted, and visible to anyone with read access to the namespace. Enable encryption at rest in etcd using an EncryptionConfiguration manifest with AES-GCM or use a KMS provider like AWS KMS, GCP CKMS, or HashiCorp Vault via the KMS plugin. For application secret injection, prefer external secret stores: External Secrets Operator syncs secrets from AWS Secrets Manager, GCP Secret Manager, or Vault into Kubernetes Secrets on a rotation schedule. Set automountServiceAccountToken: false on pods that do not need Kubernetes API access to eliminate unnecessary token exposure.
What Kubernetes RBAC mistakes create the most privilege escalation risk?
The highest-risk RBAC patterns are: binding cluster-admin to service accounts used by workloads (gives any compromised pod full cluster control), using wildcard verbs or resources (verbs: ["*"], resources: ["*"]), granting create or update on ClusterRoleBindings or Roles (allows self-escalation), granting get/list/watch on Secrets at the cluster level (exposes all secrets), and using the default service account without disabling automount. Audit with kubectl get clusterrolebindings,rolebindings --all-namespaces -o wide and focus remediation on any binding that touches cluster-admin, secrets, or RBAC objects.
How do I detect active attacks in a Kubernetes cluster?
Deploy Falco for syscall-level runtime detection with rules for shell spawned in container, sensitive mount detected, and outbound connection to non-approved destination. Enable Kubernetes audit logging and forward to your SIEM with alerting on anonymous authentication attempts, exec into running containers (reason: exec), listing secrets from unusual service accounts, and RBAC binding creation outside of CI/CD service accounts. Use kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> to audit what any service account can do before an attacker exploits it.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.