DEV Community: Indra Gusti Prasetya

Kubernetes Hardening 2026: RBAC, PSS & Unfixed CVEs

Indra Gusti Prasetya — Sat, 06 Jun 2026 12:45:46 +0000

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.

   # 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.

   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.

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 and opt workloads back in only when they genuinely call the API.

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

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.

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. 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. 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.

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

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.
```
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.

Sources

Kubernetes User Namespaces in 1.36 with hostUsers: false

Indra Gusti Prasetya — Sat, 06 Jun 2026 09:44:54 +0000

By the end of this you will have a worker node provisioned for user namespaces and a Pod whose in-container root (UID 0) maps to a powerless UID on the host, verified by reading /proc/self/uid_map instead of trusting the Pod spec. Kubernetes v1.36 shipped this as GA on 22 April 2026, and the field that turns it on, hostUsers: false, is the easy part. The node prep underneath it is where people lose an afternoon.

The reason this is worth your time over asking a model to "set up user namespaces": the working knowledge here is too new and too underdocumented for that to help. The kernel floor is 6.3, not the 5.12 everyone quotes. The failure mode when you get a dependency wrong is usually silence, not an error. And the same v1.36 upgrade that makes the feature free also deletes containerd 1.x support out from under you.

Prerequisites

Kubernetes v1.36+. UserNamespacesSupport is GA and on by default, so no feature gate. On v1.33 to v1.35 the feature works but you may still need the gate enabled.
Linux kernel 6.3 or newer on every node. idmap mounts landed in 5.12, but tmpfs idmap support (which kubelet needs for emptyDir and projected volumes) only merged in 6.3. This is the single most-missed requirement.
containerd 2.0+ or CRI-O 1.25+, backed by runc 1.2+ or crun 1.9+ (1.13+ recommended).
A node filesystem under /var/lib/kubelet/pods/ that supports idmap mounts: btrfs, ext4, xfs, fat, tmpfs, or overlayfs.
Root SSH access to a worker node, plus kubectl against the cluster.

Step-by-step

1. Confirm the kernel and runtime actually qualify

uname -r                          # need >= 6.3
containerd --version              # need >= 2.0.0
runc --version                    # need >= 1.2.0  (or: crun --version >= 1.9)
stat -f -c %T /var/lib/kubelet    # expect ext4 / xfs / btrfs / overlayfs

This checks the four things that have to be true before any YAML matters. If uname -r shows something like 5.15, stop here, because no Pod spec will fix a kernel that lacks tmpfs idmap. Cloud vendor LTS images frequently ship 5.x kernels, which is exactly why this feature fails so often in the field.

2. Create the kubelet system user and subordinate ID ranges

kubelet maps each Pod into a slice of host UIDs and GIDs that it reads from /etc/subuid and /etc/subgid, keyed to a user literally named kubelet.

# Create the user if it doesn't exist (no login shell needed)
useradd -r -s /usr/sbin/nologin kubelet 2>/dev/null || true

# Allocate subordinate IDs: 65536 * maxPods. For the default 110 pods:
#   65536 * 110 = 7208960
echo 'kubelet:65536:7208960' >> /etc/subuid
echo 'kubelet:65536:7208960' >> /etc/subgid

The arithmetic has rules the tooling enforces: the first ID must be a multiple of 65536 and at least 65536 (never the 0 to 65535 range), the count must be a multiple of 65536, and the UID and GID ranges must match. Use exactly one line per user. Multiple ranges are not supported, and a second line does not extend the first.

3. Install `getsubids` so kubelet can read those ranges

# Debian/Ubuntu
apt-get install -y uidmap
# Fedora/RHEL
dnf install -y shadow-utils

# Verify kubelet's allocation is visible:
getsubids kubelet
getsubids -g kubelet

kubelet shells out to getsubids (from shadow-utils) at startup to discover the ranges from step 2. If that binary is missing from PATH, kubelet falls back to running Pods without namespaces and emits no hard error. This is the quietest failure in the whole feature, so install the package before you rely on it.

4. (Optional) Raise the per-Pod ID count

# /var/lib/kubelet/config.yaml  (KubeletConfiguration)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
userNamespaces:
  idsPerPod: 65536        # default; must be a multiple of 65536

Leave this at the default unless a workload genuinely needs a UID range wider than 65536. If you raise it, redo the /etc/subuid math (idsPerPod × maxPods) or you will exhaust the range partway through your Pod density. Changes apply only to containers created after a kubelet restart:

systemctl restart kubelet

5. Deploy a Pod with user namespaces enabled

apiVersion: v1
kind: Pod
metadata:
  name: userns-demo
spec:
  hostUsers: false          # <-- the whole feature
  containers:
  - name: app
    image: busybox:1.36
    command: ["sh", "-c", "sleep 3600"]
    securityContext:
      runAsUser: 0          # root *inside* the container, on purpose

hostUsers: false tells kubelet to place the Pod in its own user namespace. The container believes it runs as UID 0; the host kernel sees an unprivileged UID from the kubelet subuid range. Capabilities like CAP_NET_ADMIN and CAP_SYS_ADMIN become namespace-scoped, so they are real inside the container and meaningless against the host.

kubectl apply -f userns-demo.yaml

Verify it works

Do not trust the field. Prove the mapping by reading the in-container view, then the host view, and confirming they differ.

# Inside the container: claims to be root (UID 0)
kubectl exec userns-demo -- id
# uid=0(root) gid=0(root) ...

# Inside the container: inspect the namespace's UID map
kubectl exec userns-demo -- cat /proc/self/uid_map
#          0     <hostUID>      65536

A uid_map line of 0 <some-large-number> 65536 (for example 0 65536 65536) confirms isolation: container UID 0 begins at host UID 65536, spanning 65536 IDs. The dead giveaway that it is not working is 0 0 4294967295, the identity map, which means the Pod is sharing the host user namespace despite the field being set.

Now confirm from the node itself:

# On the worker node, find the container's real host UID
ps -o pid,uid,cmd -C sleep
# UID column shows ~65536, NOT 0

Seeing a high UID like 65536 for a process that thinks it is root is the win condition. In practice, the step that bites people is skipping this node-side check: the Pod starts cleanly, kubectl exec ... id prints uid=0, and everything looks done, but if getsubids was missing in step 3 the Pod is running with the host identity map and zero added isolation. The /proc/self/uid_map line is the only thing that tells you the truth, so I treat a green Pod with no uid_map check as unverified.

Common pitfalls

Kernel 5.12 is not enough. idmap mounts exist there, but tmpfs idmap support arrived in 6.3, and kubelet needs it for emptyDir and projected volumes. On an older kernel, Pods with those volumes fail to mount.
Silent fallback when getsubids is missing. No uidmap or shadow-utils package means kubelet runs the Pod without namespaces and logs only at high verbosity. Always verify with /proc/self/uid_map, never with the spec.
hostPath and pre-existing volumes defeat it. Files owned by UIDs outside the mapped range appear as the overflow ID 65534 (nobody) and are not writable. User namespaces compose cleanly with emptyDir, projected, and idmap-capable CSI volumes, but not with arbitrary host paths.
containerd 1.x will break your upgrade. v1.36 dropped support for it (1.35 was the last release to carry it). If nodes still run 1.x, the kubelet upgrade fails regardless of user namespaces, so move to 2.0+ first.
It is mitigation, not a force field. hostUsers: false greatly reduces the blast radius of escapes like CVE-2024-21626 (the runc working-directory and leaked-fd breakout) and CVE-2022-0492 (the cgroups release_agent flaw), but the kernel is still shared. An attacker can still do whatever a file's "other" permission bits allow, and a kernel-level exploit is unaffected. Treat this as defense-in-depth alongside seccomp, Pod Security Standards, and runtime isolation, not a replacement for them.
Per-Pod range changes need a kubelet restart and only affect new containers. Running Pods keep their old mapping until recreated.

Wrap-up

You now have a node carrying kubelet subuid and subgid ranges, a runtime and kernel that actually support idmap mounts, and a Pod whose in-container root is a powerless host UID, confirmed through /proc/self/uid_map rather than faith. The highest-leverage next move is to make this the default instead of a per-Pod opt-in: bake the /etc/subuid provisioning and the kernel and runtime version floors into your node image, then write a Kyverno or Validating Admission Policy rule that mutates hostUsers: false onto every workload that does not need host UID identity. That turns a GA checkbox into a baseline the whole cluster inherits.

DEV Community: Indra Gusti Prasetya

Kubernetes Hardening 2026: RBAC, PSS & Unfixed CVEs

The tips

Wrap-up

Sources

Kubernetes User Namespaces in 1.36 with hostUsers: false

Prerequisites

Step-by-step

1. Confirm the kernel and runtime actually qualify

2. Create the kubelet system user and subordinate ID ranges

3. Install getsubids so kubelet can read those ranges

4. (Optional) Raise the per-Pod ID count

5. Deploy a Pod with user namespaces enabled

Verify it works

Common pitfalls

Wrap-up

Sources

3. Install `getsubids` so kubelet can read those ranges