Kubernetes has become the de facto standard for container orchestration in enterprise environments, and its security complexity matches its operational capabilities. A Kubernetes cluster exposes a large and interconnected attack surface — the API server, etcd, kubelet, container runtime, and every deployed workload — and misconfigurations in any of these components can provide attackers with a path to cluster-wide compromise or lateral movement across cloud environments. This guide covers the highest-impact Kubernetes security controls drawn from the CIS Kubernetes Benchmark 1.9 and operational security experience.
The Kubernetes Attack Surface
Understanding what attackers target in Kubernetes environments is prerequisite to effective hardening:
- API Server: The central control plane component. An attacker with authenticated API access and sufficient permissions can create privileged pods, read secrets, modify workloads, and potentially escape to the underlying nodes. Unauthenticated API server access (a finding that still appears in real-world assessments) is a critical incident — the entire cluster is compromised.
- etcd: The key-value store holding all cluster state, including Kubernetes Secrets in base64-encoded form. Direct etcd access is equivalent to root access on the API server. etcd should never be exposed outside the control plane network, and encryption at rest is essential.
- kubelet: The node-level agent. An exposed kubelet API (port 10250) that does not require authentication allows arbitrary pod execution on the node. CVE-2018-1002105 (anonymous kubelet access) and similar vulnerabilities have been exploited in the wild to achieve cluster-wide code execution.
- Container runtime: Vulnerabilities in container runtimes (historically runc, now primarily containerd) can allow container escape — a workload escaping its container isolation to access the host OS. Runtime vulnerabilities like CVE-2019-5736 (runc container escape) and CVE-2024-21626 have been exploited in targeted attacks against container infrastructure.
RBAC: Designing for Least Privilege
Kubernetes Role-Based Access Control (RBAC) is the authorization layer for all API server operations. RBAC misconfigurations are among the most common findings in Kubernetes security assessments:
Avoid cluster-admin Bindings
The cluster-admin ClusterRole grants unrestricted access to all resources in all namespaces. Binding this role to service accounts used by workloads, CI/CD pipelines, or developers is a critical misconfiguration. Enumerate all ClusterRoleBindings for cluster-admin and replace them with minimally scoped roles. Common legitimate use: human administrators during bootstrapping — not automated systems.
Service Account Token Minimization
By default, every Kubernetes pod is automounted with a service account token that can authenticate to the Kubernetes API. Unless a pod has a specific reason to call the Kubernetes API, set automountServiceAccountToken: false at the pod or service account level. This eliminates one of the most common lateral movement paths in Kubernetes: a container escape followed by use of the pod's service account token to interact with the API server and escalate privileges.
For pods that do need API access, use Projected Service Account Tokens (time-limited, audience-bound tokens) rather than the traditional long-lived tokens, and bind the service account to a dedicated Role with the minimum permissions required — never to cluster-admin.
Pod Security Standards
Kubernetes Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy in Kubernetes 1.25, enforced via the built-in Pod Security Admission controller. Three policy levels are defined:
- Privileged: Unrestricted. Allows privileged containers, host network/PID/IPC namespaces, any volume type. Use only for node-level infrastructure (CNI plugins, storage drivers, monitoring agents) with explicit justification.
- Baseline: Prevents known privilege escalation while allowing most workloads. Disallows privileged containers, host namespace sharing, and dangerous capabilities. Good default for general workload namespaces.
- Restricted: Hardened against known container escape techniques. Requires non-root user execution, read-only root filesystem where possible, drops all capabilities, disallows privilege escalation. Apply to application workload namespaces. Note that some applications require refactoring to comply with Restricted.
Enforce PSS at the namespace level with the pod-security.kubernetes.io/enforce label. Audit mode (logging violations without enforcement) during rollout lets you identify non-compliant workloads before hard enforcement.
Network Policies for Micro-Segmentation
Without Network Policies, all pods in a Kubernetes cluster can communicate with all other pods regardless of namespace — a flat network that provides zero lateral movement resistance. Network Policies define allow-listed ingress and egress rules for pods based on label selectors, namespace selectors, and IP blocks.
Implementation approach: deploy a default-deny policy in every namespace first, then add allow policies for each required communication path:
Apply default deny for both ingress and egress to every namespace, then explicitly allow required communications (application to database on specific port, application to external API endpoints, monitoring agent to metrics endpoint). Network policies require a CNI plugin that enforces them — Calico, Cilium, and Weave Net all support Network Policies; Flannel alone does not.
Secrets Management
Kubernetes Secrets are, by default, stored as base64-encoded data in etcd — which provides obfuscation but not encryption. Organizations that store sensitive credentials in Kubernetes Secrets without additional controls are accepting meaningful risk. The mitigation layers are:
- etcd encryption at rest: Configure the API server's
--encryption-provider-configto encrypt Secret resources using AES-GCM or KMS. For managed Kubernetes (EKS, GKE, AKS), enable the envelope encryption option that integrates with your cloud KMS (AWS KMS, Google Cloud KMS, Azure Key Vault). - External Secrets Operator: Integrates Kubernetes with external secret stores (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager). Secrets are sourced from the external store at pod startup and injected as environment variables or projected volumes — never stored in etcd. This is the recommended approach for sensitive credentials in production clusters.
- Avoid environment variable secrets: Even with encryption at rest, secrets mounted as environment variables are visible in pod specs, API server audit logs, and process listing output. Prefer file-based secret mounting with restricted permissions.
Runtime Security: Falco and Tetragon
Preventive controls (RBAC, PSS, Network Policies) reduce attack surface but do not detect post-exploitation activity. Runtime security tools monitor kernel-level events to detect anomalous behavior indicating a compromise:
- Falco: CNCF-graduated runtime security tool that uses eBPF or kernel module to capture system calls and evaluate them against a rules engine. Built-in rules detect common attack patterns: writing to
/etc/passwd, executing a shell in a container, reading sensitive files like/etc/shadow, spawning a reverse shell. Highly configurable with extensive community rule libraries. Falco alerts integrate with SIEMs, PagerDuty, Slack, and other alerting systems. - Tetragon: Isovalent's eBPF-based runtime security and observability tool. Provides fine-grained process execution tracing, network event visibility, and security policy enforcement at the kernel level. Particularly powerful for detecting and blocking container escape attempts at the system call level.
Audit Logging and the CIS Benchmark
Kubernetes API server audit logging records every request to the API server with the user, action, resource, and response code. Configuring comprehensive audit logging and shipping audit events to a SIEM is essential for both incident detection and forensic investigation. A well-tuned audit policy captures all sensitive operations (Secrets access, RBAC modifications, pod privileged creation) without generating prohibitive log volume from high-frequency read operations.
The CIS Kubernetes Benchmark 1.9 provides 100+ specific, auditable controls across the API server, etcd, kubelet, control plane configuration, and worker nodes. Running kube-bench (the open-source CIS Kubernetes Benchmark auditing tool from Aqua Security) against your clusters provides a scored baseline and prioritized remediation list.
Managed Kubernetes Security
Managed Kubernetes offerings (EKS, GKE, AKS) handle control plane security (API server, etcd, kubelet on master nodes) on your behalf, but worker node security, RBAC configuration, Network Policies, and workload-level hardening remain entirely your responsibility. Each platform provides specific security integrations: EKS with AWS IAM roles for service accounts (IRSA) and GuardDuty for runtime threat detection; GKE with Binary Authorization (signed image enforcement) and Autopilot (opinionated security defaults); AKS with Microsoft Defender for Containers and Azure Policy for Kubernetes.
Kubernetes security assessments are a specialized capability that requires deep platform knowledge and offensive security expertise. Our cloud security assessments include Kubernetes configuration review mapped to the CIS Benchmark and adversarial testing of RBAC configurations, pod security controls, and network segmentation. Our managed infrastructure service includes Kubernetes runtime monitoring with Falco integration and continuous CIS Benchmark compliance tracking. Contact us to assess your Kubernetes security posture.