Kubernetes Security Hardening Checklist (2026)

The Kubernetes control plane (API server, etcd, controller manager, scheduler) is the highest-value target in any cluster. Compromise of the control plane provides full cluster access.

API server hardening is the most critical control. The API server should never be directly exposed to the internet. If managed Kubernetes (EKS, AKS, GKE) with a public endpoint is required, enable authorized networks to restrict access to specific IP ranges. Disable anonymous authentication: --anonymous-auth=false. Enable audit logging with a comprehensive audit policy that captures all request and response bodies for sensitive resource types. Disable the insecure port (should be default off in Kubernetes 1.20+, but verify). Use the NodeRestriction admission controller to limit what kubelet can modify.

Etcd requires specific protections because it stores all cluster state, including secrets in base64 encoding. Etcd should only be accessible from the API server; no other component or operator should have direct etcd access. Enable etcd encryption at rest using the EncryptionConfiguration API with AES-GCM or AES-CBC for secret resources. Require mutual TLS for all etcd client connections. Back up etcd regularly and test restoration procedures; an etcd backup is the recovery path for most cluster disasters.

For managed Kubernetes offerings, many control plane hardening controls are managed by the provider. Verify your provider's shared responsibility model and audit the controls you retain responsibility for.

Kubernetes RBAC is the primary access control mechanism for all cluster operations. It controls who can create, read, update, and delete every Kubernetes resource type. Misconfigured RBAC is the most common path to privilege escalation in Kubernetes environments.

The principle of least privilege applies to both human users and service accounts. No user or service account should have cluster-admin unless they genuinely require full cluster access. The cluster-admin ClusterRoleBinding should have fewer than five members in most production clusters. Audit it regularly.

Service accounts are the RBAC identity used by pods. By default, every pod is mounted with the default service account token for its namespace, and that token can be used to query the Kubernetes API. For pods that do not require API access, set automountServiceAccountToken: false in the pod spec. For pods that do require API access, create a dedicated service account with the minimum required permissions and bind it explicitly.

Wildcard permissions in roles are a common misconfiguration: verbs: ["*"] or resources: ["*"] grants far broader access than intended. Audit all ClusterRoles and Roles for wildcard permissions and replace them with explicit permission lists. Pay particular attention to permissions on secrets (any principal that can read secrets in a namespace can read all secrets including credentials stored there), pods (the ability to create pods is effectively equivalent to code execution in the namespace), and deployments (anyone who can create deployments can run arbitrary container images).

Use kubectl auth can-i --list --as <serviceaccount> to audit what permissions specific identities hold. Tools like rbac-audit, rbac-police, and KubeHound automate RBAC misconfiguration detection across large clusters.

By default, all pods in a Kubernetes cluster can communicate with all other pods across all namespaces. This flat network model means a compromised pod has network access to every other service in the cluster. Network Policies implement microsegmentation: explicit allow rules that define which pods can communicate with which other pods.

The baseline posture is a default-deny policy in every namespace, followed by explicit allow rules for required communication paths. A default-deny ingress NetworkPolicy that selects all pods in a namespace blocks all inbound traffic to those pods unless another NetworkPolicy explicitly allows it. The same pattern applies to egress.

Namespace isolation is the primary segmentation boundary. Workloads with different trust levels (public-facing services, internal APIs, databases) should be in separate namespaces with NetworkPolicies that enforce explicit communication paths. A NetworkPolicy permitting the web tier to reach the API tier, the API tier to reach the database, and no lateral communication within each tier significantly limits blast radius from a pod compromise.

For clusters where standard Kubernetes NetworkPolicy is insufficient (which does not support L7 filtering or cross-cluster policies), service mesh solutions (Istio, Linkerd, Cilium) provide richer policy capabilities including mTLS between pods, L7 authorization policies, and observability for all pod-to-pod traffic. Cilium's eBPF-based network policy enforcement also provides significantly better performance than traditional iptables-based NetworkPolicy implementations at scale.

Pod security controls restrict what containers can do at the Linux capability and system call level. The Kubernetes Pod Security Admission (PSA) controller, which replaced deprecated PodSecurityPolicy in Kubernetes 1.25, enforces three security profiles: Privileged (no restrictions), Baseline (prevents known privilege escalation), and Restricted (strongest security posture).

Production workloads should run under the Restricted policy where possible. Restricted requires: running as a non-root user; setting readOnlyRootFilesystem; dropping all capabilities and only adding back what is explicitly required; disabling privilege escalation (allowPrivilegeEscalation: false); and using a non-default seccomp profile.

For containers that cannot meet Restricted requirements immediately, Baseline prevents the most critical misconfigurations: running privileged containers, mounting host paths, using hostNetwork, hostPID, or hostIPC, and using dangerous capabilities like SYS_ADMIN.

Seccomp profiles restrict which system calls a container process can make. The runtime/default seccomp profile blocks uncommon and dangerous system calls without breaking most applications. For sensitive workloads, audit mode (SCMP_ACT_LOG rather than SCMP_ACT_ERRNO) can capture which syscalls your application actually uses before creating a custom allow-list profile.

Image security is a related control: only run images from trusted registries, validate image signatures before admission using Cosign and image policy webhooks, and scan all images for known vulnerabilities in the CI/CD pipeline before they reach production.

Kubernetes Secrets are base64-encoded by default, not encrypted. Any user or service account with read access to Secrets in a namespace can decode them trivially. This creates a critical gap between the name 'Secret' and its actual confidentiality properties.

Etcd encryption at rest (covered in the control plane section) is the first required control. The second is strict RBAC on Secret reads: no service account should have wildcard secret access, and human access to production secrets should go through a break-glass process with audit logging rather than direct kubectl access.

External secrets management integrates Kubernetes with dedicated secrets stores: HashiCorp Vault via the Vault Agent Injector or External Secrets Operator, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. The External Secrets Operator (ESO) synchronizes secrets from external stores into Kubernetes Secrets on a configurable schedule, enabling rotation at the secrets store level without application changes. This approach provides a centralized audit trail, rotation automation, and access controls that are more granular than what Kubernetes RBAC alone can enforce.

Runtime threat detection provides the behavioral monitoring layer that static configuration controls cannot. Falco is the dominant open-source runtime security tool for Kubernetes: it uses eBPF or kernel module hooks to monitor system calls and generate alerts when container behavior deviates from expected patterns. Default Falco rules detect: shell execution inside containers, sensitive file reads, privilege escalation attempts, outbound connections to unexpected hosts, and cryptomining binary execution. Custom rules can be added for application-specific threat models. Feed Falco alerts to your SIEM for centralized correlation with other cluster and infrastructure events.