Kubernetes ships secure-able, not secure-by-default. Most of the meaningful hardening is opt-in, which means a default cluster has a wider attack surface than most teams assume.
RBAC: start from least privilege
Kubernetes' Role-Based Access Control is powerful but frequently misconfigured with overly broad ClusterRoles. Avoid binding cluster-admin to anything beyond genuine cluster administrators, and scope service account permissions to exactly the namespace and resources a workload needs.
Network policies aren't on by default
Without an explicit NetworkPolicy, every pod can reach every other pod in the cluster. This means a single compromised pod can potentially reach your database, internal APIs, or anything else in the cluster. Define default-deny network policies per namespace, then explicitly allow only the traffic that's actually needed.
Pod Security Standards
Kubernetes' built-in Pod Security Standards (replacing the deprecated PodSecurityPolicy) define three levels — Privileged, Baseline, Restricted. Most workloads should run under Restricted: no privileged containers, no host network access, no running as root unless explicitly required.
Secrets need an external manager for real security
Kubernetes Secrets are base64-encoded, not encrypted, by default — anyone with API read access to the Secret object can trivially decode it. Enable encryption at rest for the etcd datastore, and for anything sensitive, prefer an external secrets manager (Vault, AWS Secrets Manager) integrated via a CSI driver rather than native Kubernetes Secrets alone.
Keep the control plane and nodes patched
Kubernetes CVEs affecting the API server, kubelet, or container runtime are disclosed regularly. A patching cadence for cluster components (not just application containers) is as important as image scanning.
Admission control as a gate
An admission controller (like Kyverno or OPA Gatekeeper) lets you enforce policy at deploy time — blocking privileged containers, requiring resource limits, or requiring signed images — rather than relying on developers to remember every rule manually.
Audit logging
Enable Kubernetes audit logs and ship them somewhere durable. Without them, investigating "who did what" after an incident inside the cluster is close to impossible.
None of these individually is exotic — the risk in most clusters comes from simply never turning them on.