Every Kubernetes release cycle produces a wave of "what's new" posts, and almost all of them are written for platform teams at companies with a platform team. If you are three engineers running one cluster and no dedicated infrastructure hire, that content is worse than useless: it points you at alpha features you cannot enable and burns the attention you needed for the boring stable stuff that is already sitting in your cluster, switched off.
This post does the opposite. It covers only features that reached stable between Kubernetes v1.32 (December 2024) and v1.36 (April 2026), only the ones with a real security payoff, and only the ones a small team can turn on without hiring anybody. Every item names the version it went GA and links to the upstream source.
It also covers the part most feature roundups skip: what the same five releases removed or retired, because that is the half that will actually wake you up at 03:00. Where I am giving practitioner judgement rather than citing upstream, I have labelled it inline.
Quick context: why stable is the only tier that matters to you
Kubernetes ships three minor releases a year, and each one is supported with patches for roughly fourteen months under the project's patch release policy. Managed control planes on EKS, GKE, and AKS lag upstream by a few months, so a small team upgrading on a sane cadence is usually running something one to three minors behind the newest release. That means the v1.32 to v1.34 features below are almost certainly available in your cluster right now, and the v1.35 and v1.36 ones are what you are upgrading into.
Stable also means something specific: the feature gate is on by default, the API will not change under you, and it will not be yanked in the next release. For a team with no capacity to babysit alpha features across upgrades, that is the only tier worth building policy on.
Takeaway: check your control plane minor version first (kubectl version). Everything below is filtered by which of these five releases you are past.
1. Restrict anonymous requests to an explicit endpoint list (stable in v1.34)
By default, the API server has historically bound system:anonymous and the system:unauthenticated group, which is fine until an RBAC mistake binds a role to that group and suddenly the internet has a service account. KEP-4633, stable in v1.34, lets you allow anonymous auth only for a named list of endpoints instead of turning it on or off wholesale.
In practice you configure AuthenticationConfiguration with anonymous.conditions restricted to /healthz, /livez, and /readyz. Load balancers and probes keep working. Every other path returns 401 to an unauthenticated caller, and an accidental ClusterRoleBinding to system:unauthenticated stops being a full cluster compromise.
This is the single highest value-to-effort item on this list for a small team, because the misconfiguration it defends against is one someone on your team will eventually make while debugging at speed.
Takeaway: if you run your own control plane, set the anonymous allowlist to the three health endpoints. If you are on a managed service, confirm what your provider has configured rather than assuming.
2. Structured authorization configuration (stable in v1.32)
KEP-3221 went GA in v1.32 and replaces the old single --authorization-mode flag with a config file that defines an ordered chain of authorizers, each with CEL match conditions. It is enabled by default with no feature gate.
The security value is not the multi-webhook support, which most small teams do not need. It is the CEL conditions. You can now scope an authorization webhook so it is only consulted for requests that actually matter, which means a webhook outage degrades a narrow slice of your cluster instead of the whole thing, and you can express rules that RBAC alone cannot.
Practitioner opinion: for a pre-seed team, the correct use of this feature is restraint. Keep the chain short, keep RBAC as the primary authorizer, and use CEL conditions to fail closed on a specific dangerous verb-resource pair rather than to build a bespoke policy engine you will not maintain.
Takeaway: know this exists so that when you eventually add an external authorizer, you wire it in as a scoped link in a chain instead of an all-or-nothing mode switch.
3. Authorize with field and label selectors (stable in v1.34)
KEP-4601, stable in v1.34, lets authorizers make decisions based on the field and label selectors attached to a list, watch, or deletecollection request.
This closes a gap that has bitten every team that ever tried to write least-privilege RBAC for a controller. Classic RBAC grants verbs on resource types, not on subsets of objects. A workload that legitimately needs to watch its own pods has historically needed list and watch on pods, which means it can enumerate every pod in the namespace, read every pod spec, and harvest every mounted secret name. With selector-aware authorization, a request can be authorized only when it carries a selector that constrains it to the objects the caller should see.
For a small team the immediate beneficiaries are the third-party agents you install without reading their RBAC: log shippers, cost tools, dashboards. Those charts routinely request cluster-wide list and watch.
Takeaway: audit what your installed Helm charts actually request with kubectl get clusterrole -o yaml and grep for cluster-wide list on pods and secrets. That is your blast radius today.
4. Fine-grained kubelet API authorization (stable in v1.36)
This is the most important item in the v1.36 release for anyone running monitoring. KEP-2862 graduated to GA and splits the kubelet's HTTPS API into individually authorizable subresources.
Before this, reaching any kubelet endpoint meant granting nodes/proxy. That single permission covers /exec, /run, and /attach alongside /healthz and /pods. Granting it to a metrics scraper so it can read a health endpoint hands that scraper the ability to run arbitrary commands in every container on every node. It is a node-level superuser grant dressed up as read access, and it sits in a very large number of monitoring stacks installed by default.
With fine-grained authorization you grant nodes/healthz, nodes/pods, or nodes/configz individually, and the compromise of an observability agent stops being a cluster takeover.
Takeaway: run kubectl get clusterrolebindings -o wide and find every subject holding nodes/proxy. On v1.36, replace each with the narrow subresource it actually needs. Practitioner opinion: this is the highest-yield hour of RBAC work available in a typical startup cluster.
5. Bound ServiceAccount token improvements (stable in v1.33)
Projected service account tokens got two additions that reached stable in v1.33, per the CNCF's 2025 security roundup: a unique identifier embedded in every token, and optional binding of a token to the node its pod is scheduled on.
Both are detection and containment features rather than prevention. The unique token ID means an exfiltrated token is traceable in audit logs to the exact issuance event, which turns "someone used this service account" into "this specific token, issued to this pod at this time, was replayed from elsewhere". Node binding means a token lifted off one node and replayed from another is rejected outright.
Neither requires application changes. They are properties of how the token is issued and validated, so the work is configuration plus making sure your audit logs are actually being retained somewhere you can query.
Takeaway: token theft via a compromised pod is the most common lateral movement path in a Kubernetes breach. Node binding removes the easiest version of that move for free.
6. User namespaces reach GA (stable in v1.36)
After alpha in v1.25 and a long beta, user namespaces (KEP-127) are stable and enabled by default in v1.36. Set hostUsers: false on a pod spec and root inside the container maps to an unprivileged, non-overlapping user on the host.
The upstream documentation is unusually direct about the payoff: several vulnerabilities rated HIGH or CRITICAL were not exploitable when user namespaces were active. Capabilities granted to the pod are confined to the pod's own user namespace, so CAP_SYS_MODULE cannot load kernel modules and CAP_SYS_ADMIN loses its host-level reach. Because each pod maps to a distinct host UID range, pods also lose the ability to interfere with each other through the filesystem.
The catch is the node requirements, and they are real: Linux 6.3 or later, containerd 2.0+ or CRI-O 1.25+, runc 1.2+ or crun 1.9+, and a filesystem supporting idmap mounts under /var/lib/kubelet/pods/. On a managed node pool this is a question for your provider, not a knob you turn.
Takeaway: this is the strongest container-breakout mitigation the project has shipped. Verify node support, then enable it namespace by namespace starting with anything that processes untrusted input.
7. Recursive read-only mounts and native sidecars (both stable in v1.33)
Two v1.33 graduations that pair well. Recursive read-only mounts fix a long-standing gap where marking a volume readOnly did not necessarily make nested submounts read-only, leaving writable paths inside a mount you believed was locked. With recursiveReadOnly: Enabled, read-only means read-only all the way down.
Native sidecar containers (KEP-753) landed as init containers with restartPolicy: Always. They start before app containers, run for the pod's full lifetime, support probes, and no longer block Job completion. For security specifically, this is what makes an agent-based control reliable: your log shipper or runtime sensor is guaranteed to be up before the workload it is watching, and it stops being the reason your CronJobs hang forever.
Takeaway: convert security sidecars to native sidecars on your next deployment edit. It is a two-line change that removes a whole class of ordering bugs, and it is the difference between a sensor that observes the first ten seconds of a pod's life and one that does not.
8. Ordered namespace deletion (stable in v1.34)
KEP-5080, stable in v1.34, changes namespace teardown from an unordered free-for-all to an opinionated sequence. The specific bug it fixes: deleting a namespace could remove its NetworkPolicies while pods in that namespace were still running, leaving those pods briefly unprotected on the network during termination.
That window is short and easy to dismiss. It should not be dismissed. Namespace deletion is a common step in CI teardown, in ephemeral preview environments, and in incident response when someone is trying to contain a compromised workload. Containment is exactly the moment you least want the network policy to evaporate before the pod does.
The feature is on by default with no configuration. You get it by upgrading past v1.34.
Takeaway: if your incident runbook says "delete the namespace" as a containment step, this is one of the reasons to prioritise reaching v1.34. Practitioner opinion: cordon and delete the pods first regardless, then the namespace.
9. Image pull authorization and OCI volume sources (v1.35 beta, v1.36 stable)
Two related changes on the image path. First, robust image pull authorization (KEP-2535) reached beta in v1.35, per the CNCF roundup. Historically, once an image was cached on a node, any pod on that node could use it without re-proving it had credentials for the source registry. On a shared node that is a tenant isolation hole. The kubelet now re-verifies credentials for cached images, controlled by imagePullCredentialsVerificationPolicy, without forcing imagePullPolicy: Always and eating the pull latency.
Second, OCI volume sources (KEP-4639) reached stable in v1.36 after beta in v1.33. You can mount the contents of an OCI image as a read-only volume, which removes a family of init containers and startup scripts that existed only to fetch config, models, or static assets. Fewer init containers doing network fetches at startup means fewer places a supply-chain substitution can happen.
Takeaway: if you run any multi-tenant or untrusted workloads on shared nodes, image pull credential verification is the control you were missing. Practitioner opinion: replace asset-fetching init containers with image volumes when you touch them, not as a migration project.
10. What was removed or retired, which is the half that breaks you
Three items across these releases will cause an outage or a vulnerability if you ignore them.
Ingress NGINX is retired. The Kubernetes project announced in November 2025 that best-effort maintenance for kubernetes/ingress-nginx continues only until March 2026, after which there are no further releases, no bug fixes, and no security patches. The stated reasons are a maintainer base of one or two people working evenings, accumulated technical debt, the security exposure of arbitrary config injection through snippet annotations, and the failure of the InGate successor project to mature. Existing deployments keep running, which is precisely the trap: nothing breaks on the retirement date, so nothing prompts you to act until the first unpatched CVE.
That risk is not theoretical for this component. In March 2025 the maintainers patched CVE-2025-1974, an unauthenticated remote code execution chain in the admission controller rated CVSS 9.8. A comparable bug found after retirement gets no patch. Note the naming confusion: only the community kubernetes/ingress-nginx controller is retiring. The Ingress API itself remains supported but feature-frozen, and F5's separate nginxinc/kubernetes-ingress controller is a different project. Upstream points migrations at Gateway API.
The gitRepo volume is gone. Deprecated since v1.11, the plugin is permanently disabled in v1.36 and cannot be re-enabled. It allowed code execution with root privileges on the node.
Service externalIPs is deprecated. The v1.36 release notes flag it as a long-standing man-in-the-middle vector documented in CVE-2020-8554, with removal planned for v1.43.
Takeaway: grep your manifests for gitRepo, externalIPs, and your ingress controller image today. Two of the three are silent failures.
Summary table
| Change | Stable in | What it buys you | Effort |
|---|
| Restrict anonymous requests (KEP-4633) | v1.34 | An RBAC slip on system:unauthenticated stops being a cluster compromise | Low |
| Structured authorization config (KEP-3221) | v1.32 | Scoped authorizer chains with CEL conditions | Medium |
| Authorize with selectors (KEP-4601) | v1.34 | Least privilege for controllers and third-party agents | Medium |
| Fine-grained kubelet authz (KEP-2862) | v1.36 | Retires nodes/proxy as a de facto node superuser grant | Low |
| Bound SA token improvements | v1.33 | Traceable token IDs, node-bound tokens resist replay | Low |
| User namespaces (KEP-127) | v1.36 | Container root maps to an unprivileged host user | Medium, node support required |
| Recursive read-only mounts | v1.33 | Read-only actually applies to nested submounts | Low |
| Native sidecars (KEP-753) | v1.33 | Security agents start first and never block Jobs | Low |
| Ordered namespace deletion (KEP-5080) | v1.34 | NetworkPolicies outlive the pods they protect | None, on by default |
| Image pull authorization (KEP-2535) | v1.35 beta | Cached images still require registry credentials | Low |
| Ingress NGINX retirement | March 2026 | Action required: no further security patches | High |
What to do at your stage
Pre-seed, one cluster, no dedicated infra hire. Do three things. Restrict anonymous auth to health endpoints. Find and remove every nodes/proxy grant you did not deliberately make. Decide your ingress migration path and put a date on it. Everything else can wait for your next upgrade window. Practitioner opinion: the ingress decision is the one with a real deadline attached, and the longer you leave it the more annotation-specific behaviour you will have to reverse-engineer.
Seed, multiple environments, first compliance conversations starting. Add native sidecars for your security agents, recursive read-only mounts on anything mounting config, and an audit of what your installed Helm charts request cluster-wide. Plan the v1.36 upgrade around user namespaces rather than treating it as routine, because the node requirements may force a node pool change.
Series A, multi-tenant or regulated workloads. User namespaces and image pull credential verification move from good ideas to table stakes, particularly if you run customer-supplied code or share nodes across tenants. Selector-based authorization is worth the effort here because you now have enough controllers for cluster-wide list permissions to be a genuine finding in a customer security review.
The pattern across all three stages is the same. The stable tier of the last five releases quietly closed several of the gaps that generic Kubernetes hardening guides still tell you to work around with third-party tooling. Turning on what you already have beats buying something new.
If you want a second pair of eyes on which of these your cluster is actually missing, I do a short no-obligation review of a real cluster's RBAC and pod security posture and tell you what I would fix first. No NDA needed for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, Singapore, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. Feature graduation versions come from upstream Kubernetes sources: the v1.33 and v1.36 release announcements, the fine-grained kubelet authorization GA post, the user namespaces documentation feature-state banner, and the KEP records for 3221, 4601, 4633, and 5080. The v1.32 to v1.35 security summary and the v1.35 beta status of KEP-2535 are from the CNCF's 2025 stable features and 2026 preview. Ingress NGINX retirement terms and reasoning are quoted from the project's November 2025 announcement; CVE-2025-1974 details are from the official advisory post. Support windows are from the patch release policy. No client environments, audit counts, or engagement outcomes are referenced anywhere in this post. Prioritisation, effort ratings, and stage recommendations are practitioner judgement, not upstream guidance. Feature gates and provider defaults change between releases; verify against your own cluster version before acting.
