Kubernetes Hardening 2026: RBAC, PSS & Unfixed CVEs

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.

TL;DR: Label the namespace warn=restricted before you ever set enforce=restricted, delete every cluster-admin binding you cannot justify by name, turn off auto-mounted service account tokens, and ship a default-deny NetworkPolicy with each new namespace. Three CVEs now carry no fixed version, so those get configuration mitigations and a risk-register entry instead of a patch. Push all of it into the namespace template rather than into a quarterly audit.

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.

What do you fix in the first hour?

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, against the three profiles Kubernetes sets out in its Pod Security Standards reference. 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.

# Observe without breaking anything
kubectl label ns payments \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted
# Once the warnings are clean:
kubectl label ns payments pod-security.kubernetes.io/enforce=restricted --overwrite

Hunt down every cluster-admin binding and justify it out loud. More than half of the production clusters I have assessed carry at least one RBAC misconfiguration that lets a compromised pod climb to cluster-admin. The fastest win is listing every wildcard and every cluster-admin grant, then asking, per binding, whether that human or workload still needs it. Kubernetes maintains an RBAC good practices guide whose privilege-escalation section reads like an inventory of the bindings I keep finding.

kubectl get clusterrolebindings -o json | jq -r \
  '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

Watch the escalate, bind, and impersonate verbs especially, plus create on pods. Any one of them is a quiet path to full takeover, and they rarely look dangerous in a code review.

How does a compromised pod reach the control plane?

Turn off auto-mounted service account tokens. Roughly 87% of clusters in audits still mount a token into every pod running under the namespace default service account. That token is a finished credential sitting in the filesystem, waiting for anyone who lands a shell. Disable it at the service account level, opt workloads back in only when they genuinely call the API, and move those onto bound, short-lived tokens.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: payments
automountServiceAccountToken: false

From a mounted token onward there are only two branches worth drawing, and RBAC picks which one you get:

Give every namespace a default-deny NetworkPolicy on the day it is created. With no policy in place, every pod can reach every other pod across namespaces, flat and open, and most teams never see it because nothing is logging the traffic. Lay down a deny-all baseline, then add explicit allow rules on top. Bake it into your namespace template so no namespace ever ships without one.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-all, namespace: payments }
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

One gotcha that has bitten me: confirm your CNI actually enforces policy. Calico and Cilium do, but some managed clusters hand you a NetworkPolicy API that silently does nothing because enforcement was never switched on. If Cilium carries your enforcement, read the 1.19 upgrade traps before you lean on it.

Which Kubernetes CVEs will never get a patch?

Treat creating or editing Ingress objects as a privileged operation. IngressNightmare (CVE-2025-1974, CVSS 9.8) let attackers inject arbitrary NGINX config through the ingress-nginx admission controller and read every secret in that controller's service account scope, which SentinelOne's IngressNightmare analysis walks through step by step. Patching the controller matters, but the durable fix is RBAC: stop handing Ingress create and update rights to every developer namespace by default. Check who actually holds it.

kubectl auth can-i create ingress --as=system:serviceaccount:dev:builder -n dev

Mitigate the CVEs that will never get a patch. On June 1, 2026 the SRC corrected the records for CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 to show no fixed version, a decision the project explains in its post on reconciling unfixed Kubernetes CVEs. They are architectural trade-offs, not coding bugs, so scanners that used to stay quiet will now alert and you cannot version-bump your way out. The answer is configuration:

• CVE-2020-8561 (webhook redirect): run the API server with --profiling=false and keep audit log verbosity under level 10.
• CVE-2021-25740 (cross-namespace endpoint forwarding): restrict write access to Endpoints and EndpointSlice objects via RBAC.
• CVE-2020-8562 (DNS TOCTOU): run a local DNS cache with an enforced min-cache-ttl.

Write these up as accepted-with-mitigation in your risk register. The point is so the next engineer doesn't burn a day chasing a patch that does not exist.

Which defaults belong in every manifest?

Spell out non-root, read-only root filesystem, and dropped capabilities in every securityContext. The restricted PSS profile already requires these, but admission labels get loosened during incidents and stay loosened. Putting the block directly in your manifests means the protection survives a sloppy label change. This single stanza closes most container-escape and privilege-escalation primitives before they start.

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities: { drop: ["ALL"] }
  seccompProfile: { type: RuntimeDefault }

Run kube-bench and treat the CIS Benchmark as a backlog, not a one-time report. The CIS Kubernetes Benchmark has 200+ checks and you will not clear them in a sprint. Run kube-bench against the control plane and worker nodes, then triage by blast radius: RBAC, Pod Security, network policy, etcd encryption, and audit logging come first; cosmetic file-permission findings can wait.

kubectl run kube-bench --rm -it --image=aquasec/kube-bench:latest \
  --restart=Never -- run --targets node

Encrypt etcd secrets at rest, then prove it actually happened. By default, Secrets are base64-encoded in etcd, which is encoding, not encryption, and anyone who reads the datastore reads your passwords. Enable an EncryptionConfiguration with a KMS provider, or at minimum aescbc, then verify by pulling the raw etcd value and confirming it is ciphertext rather than your credentials in plain sight.

ETCDCTL_API=3 etcdctl get /registry/secrets/payments/db-creds | hexdump -C | head

How do you catch drift after the hardening pass?

Deploy a runtime scanner and route its findings somewhere a human reads weekly. Static hardening starts drifting the moment developers ship the next change. Trivy Operator (or Kubescape) scans workloads, RBAC, and images in-cluster continuously and exposes the results as CRDs you can alert on. The install is the easy part. The discipline is someone reviewing the vulnerabilityreports and rbacassessmentreports on a real cadence instead of letting them pile up. Pair it with a detector that watches syscalls, since Falco, Tetragon, and Tracee answer different questions.

kubectl get vulnerabilityreports -A
kubectl get configauditreports -A --sort-by=.report.summary.criticalCount

Wrap-up

If you change one habit, make it this: push hardening into namespace creation instead of into a quarterly audit. A namespace template that ships a default-deny NetworkPolicy, automountServiceAccountToken: false, a scoped developer RoleBinding, and the restricted Pod Security label means every new team starts from a safe floor rather than an open one. Hardening that relies on people remembering decays between reorgs; hardening that is the default holds. Get the floor right and every other item on this list becomes far easier to enforce.

The same floor logic applies to what runs on top of the cluster, which is where the 2026 AI-agent and infrastructure security checklist carries on. If you want this pass run against your clusters by someone who has done it before, tell me what you are running.

FAQ

What replaced PodSecurityPolicy in Kubernetes 1.25 and later? Pod Security Admission, built into the API server and driven by namespace labels. Set warn and audit to restricted first, fix what they flag, then set enforce.

Why does my NetworkPolicy do nothing? The API accepts and stores the object on any cluster, so if CNI enforcement was never switched on you get a resource that looks applied and drops nothing. Verify with real traffic, not with kubectl get.

Is there a patch for CVE-2020-8561, CVE-2020-8562 or CVE-2021-25740? No. All three now show no fixed version, so they get the configuration mitigations above plus a risk-register entry that says why no release is coming.

How do I find which service accounts can escalate to cluster-admin? List the ClusterRoleBindings pointing at cluster-admin, then grep your roles for escalate, bind, impersonate, and create on pods. Confirm per identity with kubectl auth can-i --as=.

Does setting automountServiceAccountToken to false break my workloads? Only the pods that call the Kubernetes API, which is a small minority. Flip it, deploy, and watch controllers and operators for 401s, then mount the token back at the pod level for those.