I have yet to clean up a breached cluster that fell to a clever zero-day. The pattern is always duller: a service account auto-mounted a token nobody scoped, a namespace shipped with no network policy, and a cluster-admin binding granted years ago for "just this one migration" was never pulled. Kubernetes defaults are tuned for compatibility, so hardening is work you do after install, not something the platform hands you. Below is the checklist I actually run against production clusters in 2026, in roughly the order that buys the most safety per hour. Two things shifted this year: RBAC-driven takeovers tied to bugs like IngressNightmare, and a June 1, 2026 correction from the Kubernetes Security Response Committee that reclassified several CVEs as permanently unfixed, which means your scanners are about to start shouting about them.
The tips
Enforce Pod Security Standards at restricted, but get there through warn first. PodSecurityPolicy is gone; Pod Security Admission (built in since 1.25) replaces it and works per namespace via labels. If you jump straight to enforce: restricted, you will reject running workloads and get paged at 3am. Apply warn and audit first, read what they flag, fix the offending pods, then flip enforce on.
