Kubernetes ships with flexibility, not security, as its default posture. Every open port, permissive RBAC role, and unrestricted pod is an invitation. Hardening a cluster means systematically closing those gaps without breaking the workloads that depend on them. This isn't a checklist exercise—it's an ongoing discipline that touches identity, network, workload, and supply chain layers.
Lock Down the Control Plane First
The API server is the single most valuable target in any cluster. Start by disabling anonymous authentication and enforcing strong authentication methods—OIDC integration with your identity provider is preferable to static tokens or client certificates that never expire. Restrict access to the etcd datastore, since it holds every secret and config object in plaintext unless encryption at rest is enabled. Enable encryption for secrets using a KMS provider rather than relying on base64 encoding, which offers zero real protection. Audit logging should be turned on from day one; without it, you have no forensic trail when something goes wrong.
RBAC: Least Privilege, Not Convenience
The most common misconfiguration in production clusters is overly broad RBAC bindings—cluster-admin granted to service accounts that only need to read pods in one namespace. Build roles around actual job functions and scope them to namespaces wherever possible. Avoid wildcard verbs and resources in Role and ClusterRole definitions. Regularly audit bindings with tools like kubectl auth can-i --list or rbac-lookup to catch privilege creep. Service accounts deserve the same scrutiny as human users—disable automounting of service account tokens for pods that don't need API access.
Pod Security: Assume Compromise
Pod Security Admission (which replaced the deprecated PodSecurityPolicy) lets you enforce baseline or restricted profiles at the namespace level. At minimum, disallow privileged containers, host namespace sharing, and privilege escalation. Set runAsNonRoot: true and drop all Linux capabilities by default, adding back only what's explicitly required. Read-only root filesystems prevent attackers from writing malicious binaries into a running container. These controls matter because a container escape or exploited application vulnerability shouldn't translate into full node compromise.
Network Policies Are Not Optional
By default, every pod in a Kubernetes cluster can talk to every other pod. That flat network model is a lateral movement dream for attackers. Implement NetworkPolicy resources to enforce default-deny ingress and egress, then explicitly allow only the traffic flows your applications require. This requires a CNI plugin that actually supports NetworkPolicy enforcement—Calico, Cilium, and others fill this role since the base Kubernetes network model doesn't enforce anything on its own. Segmenting namespaces by trust boundary and layering policies on top gives you real defense in depth.
Image and Supply Chain Integrity
Hardening doesn't stop at runtime configuration—it starts with what you deploy. Scan container images for known vulnerabilities before they reach your registry, and enforce that only signed, verified images can run in your cluster using admission controllers like Kyverno or OPA Gatekeeper. Pin image tags to digests rather than mutable tags like latest, which can silently change underneath you. Restrict which registries pods are allowed to pull from, closing off a common path for supply chain attacks where compromised or typosquatted images slip into production.
Secrets Management Beyond Kubernetes Defaults
Native Kubernetes Secrets are better than nothing, but they're not a true secrets management solution. Consider integrating an external secrets manager—Vault, AWS Secrets Manager, or similar—and injecting secrets at runtime rather than storing them as cluster objects. If you must use native Secrets, ensure etcd encryption is enabled and RBAC tightly restricts read access, since any pod or user with get permission on secrets in a namespace can exfiltrate credentials.
Continuous Verification, Not One-Time Setup
Hardening configurations drift over time as new workloads get deployed and priorities shift toward speed over security. Tools like kube-bench check compliance against the CIS Kubernetes Benchmark, while kube-hunter can simulate attacker reconnaissance against your cluster. Bake these checks into CI/CD pipelines so misconfigurations get caught before they reach production rather than during an incident response call.
Kubernetes hardening is less about a single silver-bullet control and more about layering defenses across identity, network, workload, and supply chain—so that a failure in one layer doesn't cascade into full compromise. For more on cloud infrastructure security patterns and defensive tooling, explore related segments on Korra Studio's DEFENSE_GRID platform.
