Kubernetes 1.36 will be released soon, bringing 60 enhancements. Of particular note is the effort made to improve dynamic resource allocation (DRA).

In terms of security, there are 22 changes spanning admission control configurations, certificate handling, and more.

Let’s dig in!

Security changes in Kubernetes 1.36 that may break things

#5707 Deprecate service.spec.externalIPs

SIG group: sig-network
Stage: Deprecation to Deprecation/Removal
Feature Gate: AllowServiceExternalIPs Default: true

The service.spec.externalIPs allowed non-privileged users to claim arbitrary addresses without proper authorization or validation. It has long been considered a security risk because it can enable man-in-the-middle attacks and other exploits.

⚠️ Starting with Kubernetes 1.36, this field will be deprecated. The whole process will be performed in four stages:

• 1.36 adds the AllowServiceExternalIPs feature gate to stop kube-proxy from programming rules for externalIPs.
• Around 1.40, the feature gate will be disabled by default.
• Around 1.43, the feature gate will be completely disabled, and the related code will be removed from kube-proxy.
• Around 1.46, the AllowServiceExternalIPs feature gate and the DenyServiceExternalIPs admission controller will be removed.

✅ Disable the AllowServiceExternalIPs feature gate as soon as possible. If you are actively using externalIPs, plan to implement a more secure alternative.

#3104 Separate kubectl user preferences from cluster configs

SIG group: sig-cli
Stage: Major Change to Beta
Feature Gate: StorageVersionMigrator Default: true

Starting in Kubernetes 1.35, a new kuberc configuration file cleanly separates cluster credentials and server configurations from user-specific preferences.

In Kubernetes 1.36, some features have been added, such as support for credential plugin policy/allowlist via kubectl kuberc set.

⚠️ Important change from alpha: The name field that was considered an alias of command is now deprecated.

✅ Review your configuration files and replace the name field with command in your user-specific preferences.

#4317 Pod certificates

SIG group: sig-auth
Stage: Major Change to Beta
Feature Gate: PodCertificateRequest Default: true

In Kubernetes 1.35, this enhancement allowed you to use the certificate signing request API to provide certificates for your workloads. This included the PodCertificateRequest API and a PodCertificate volume source.

⚠️ Kubernetes 1.36 combines the PKIXPublicKey and ProofOfPossession fields into a new StubPKCS10Request field. This aligns better with the most popular CA implementations, which require a PKCS10 request as input when issuing a certificate.

✅ Review your PodCertificateRequest configuration, and update the configuration when upgrading to 1.36.

#4858 IP/CIDR validation improvements

SIG group: sig-network
Stage: Graduating to Beta
Feature Gate: StrictIPCIDRValidation Default: true

This enhancement strengthens the validation of IPs and CIDRs to avoid ambiguous values that can lead to security incidents like those described in CVE-2021-29923.

In particular, it covers addresses with leading zeros like 012.000.001.002, and IPv4 addresses mapped to IPv6 ones, like ::ffff:1.2.3.4.

⚠️ Although existing values won’t break your cluster, applying a configuration with a new invalid value will throw an error.

✅ Review your configuration and correct your values where needed.

#4817 DRA: Resource Claim Status with possible standardized network interface data

SIG group: sig-node
Stage: Major Change to Beta
Feature Gate: DRAResourceClaimDeviceStatus Default: true
Feature Gate: DRAResourceClaimGranularStatusAuthorization Default: true

Dynamic Resource Allocation (DRA) is a feature added to Kubernetes to better allocate access to specialized hardware (such as GPUs or FPGAs). Pods can request access to these resources by creating ResourceClaim objects.

This enhancement defines how DRA drivers can report device status data within these ResourceClaim objects. For example, a shared network interface could list the IP addresses assigned to it. It would look something like this:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: macvlan-eth0
spec:
...
status:
  allocation:
    devices:
      results:
      - device: eth0
        driver: resource-driver.example.com
        pool: nic-worker-a
        request: macvlan-eth0
        shareID: 8e7acdf9-0290-4ecd-a801-a654b021d2b7
        consumedCapacity:
          resource-driver.example.com/bandwidth: 1G
  devices:
  - conditions:
    - lastTransitionTime: "2025-10-21T08:38:17Z"
      message: Device successfully allocated and assigned to the pod
      reason: NetworkReady
      status: "True"
      type: NetworkReady
    device: eth0
    driver: resource-driver.example.com
    networkData:
      hardwareAddress: 00:01:ec:84:fb:51
      interfaceName: net1
      ips:
      - 10.10.1.2/24
      - 2001:db8::1/64
    pool: nic-worker-a
    shareID: 8e7acdf9-0290-4ecd-a801-a654b021d2b7

⚠️ Starting with Kubernetes 1.36, components that only needed the update or patch permissions to update resourceclaims/status now require additional permissions. The DRAResourceClaimGranularStatusAuthorization feature gate controls this behavior.

✅ Check the migration guide and update your configuration to grant the additional permissions needed.

Other deprecations

These are some old deprecations you should also keep in mind when upgrading to Kubernetes 1.36:

• #5040 The gitRepo volume driver has been removed, after being deprecated since v1.11.
• The Ingress NGINX is also retired.
• WebSockets have replaced SPDY, and your RBAC policies may need updating.

Net new security enhancements in Kubernetes 1.36

#5793 Manifest-based admission control config

SIG group: sig-api-machinery
Stage: Net New to Alpha
Feature Gate: ManifestBasedAdmissionControlConfig Default: false

This change aims to move the admission control configuration, currently stored in etcd, to file-based manifests in the kube-apiserver.

Historically, Kubernetes has trusted etcd as a source of truth, including security rules. This represents a circular dependency issue, as the security system is stored in the same place that it's protecting. This presents several problems:

• The startup gap: These objects are created by the admission controller, which is not active at startup. This means there's a window where the policies are not yet enforced, creating a vulnerability.
• Policy deletion: A malicious actor with enough privileges could delete admission policies.
• Startup etcd dependency: If etcd becomes corrupted or unavailable at startup, admission policies won't be loaded properly.

⚠️ Switching on the feature flag won't be enough to enable this change. You will need to add the admission-config.yaml file.

✅ Enable the AdmissionConfiguration file by adding:

--admission-control-config-file=/etc/kubernetes/admission-config.yaml

Kubernetes 1.36 will enable these security features by default

#4828 Flagz for Kubernetes components

SIG group: sig-instrumentation
Stage: Graduating to Beta
Feature Gate: ComponentFlagz Default: true

Similar to the statusZ page, the flagz endpoint provides runtime diagnostics for Kubernetes components. In particular, it will provide the command-line arguments that were used to start a component.

Cluster administrators can use this tool to ensure that all components are running with the expected configuration and that there are no deviations from security policies.

ℹ️ Read more in Kubernetes 1.32 - What’s New?

#5284 Constrained impersonation

SIG group: sig-auth
Stage: Graduating to Beta
Feature Gate: ConstrainedImpersonation Default: true

Impersonation allows a user to act as another user, which is useful for internal tooling, such as an admin debugging an authorization policy.

The problem is that the current mechanism also allows users to impersonate other users with more permissions than originally intended. This is why the new constrained impersonation feature adds an extra check to limit users' permissions when impersonating.

ℹ️ Read more in Kubernetes 1.35 - What’s New?

Kubernetes 1.36 changes in other existing features

#4192 Move storage version migrator in-tree

SIG group: sig-api-machinery
Stage: Major Change to Beta
Feature Gate: StorageVersionMigrator Default: true

Back in Kubernetes 1.30, this enhancement enabled migrating stored data internally. Before this, migrating to a new schema version or a new encryption key required manually extracting and rewriting the data using kubectl get <resource> | kubectl replace -.

This not only doesn’t scale, but also extracting all this data is a security risk.

Thanks to this enhancement, you now only need to run a kubectl apply -f.

⚠️ Starting with Kubernetes 1.36, the CRD's status.storedVersions field will only contain the latest version of the resource so that admins can remove the old versions.

ℹ️ Check this feature’s documentation for the full details.

#5607 Allow HostNetwork Pods to use user namespaces

SIG group: sig-node
Stage: Major Change to Alpha
Feature Gate: UserNamespacesHostNetworkSupport Default: false

Starting with Kubernetes 1.35, pods that tap directly into the host network with hostNetwork: true can also use user namespaces instead of host ones with hostUsers: false. With user namespaces, an attacker who succeeds at escaping a compromised container will have reduced permissions at the host level.

ℹ️ In Kubernetes 1.36, nodes using hostNetwork: true and hostUsers: false will only be scheduled in nodes that explicitly declare support for this feature.

Kubernetes 1.36 security features graduating to Stable

#127 Support user namespaces in pods

SIG group: sig-node
Stage: Graduating to Stable

User namespaces increase Pod isolation by separating the user running processes in the container from the users in the host.

This is particularly useful for Pods that need to run as root. You can leverage user namespaces to run processes as root inside the Pod, while they are actually running as unprivileged in the host.

If such a Pod is compromised and the attacker manages to break out of the container, the impact will be limited, as the attacker will be an unprivileged user.

You can enable this feature by setting hostUsers: false in your Pod description.

ℹ️ Read more in Kubernetes 1.25 - What’s New?

#740 API for external signing of service account tokens

SIG group: sig-auth
Stage: Graduating to Stable

For some time, the kube-apiserver has been able to use external key management solutions to sign and verify service account credentials. This feature is now considered stable.

ℹ️ Check the documentation for the full information.

#1710 Speed up recursive SELinux label change

SIG group: sig-storage
Stage: Graduating to Stable

This feature speeds up the mounting of PersistentVolumes when using SELinux. By using the context option at mount time, Kubernetes applies the security context to the entire volume rather than recursively changing the context on the files.

This enhancement has been in development since Kubernetes 1.24, and is finally considered stable.

ℹ️ Read more in Kubernetes 1.30 - What’s new?

#2862 Fine-grained Kubelet API authorization

SIG group: sig-node
Stage: Graduating to Stable

This improvement grants more granularity to the current access control for node endpoints. Imagine, for example, that you had an agent that needed to list Pods on a Node. Previously, you had to grant the nodes/proxy permission. This clearly violates the least privilege principle!

With fine-grained Kubelet API authorization, you can grant access to resources like:

• nodes/configz
• nodes/healtz
• nodes/pods

ℹ️ Read more in Kubernetes 1.33 - What’s new?

#3962 Mutating admission policies

SIG group: sig-api-machinery
Stage: Graduating to Stable

Most of the mutations an admission controller makes are simple edits, like setting labels and fields or adding sidecars. This enhancement added a mechanism to define these changes directly in YAML using Common Expression Language (CEL), eliminating the need for a webhook in most cases.

ℹ️ Read more in Kubernetes 1.31 - What’s new?

#2258 Node log query

SIG group: sig-windows
Stage: Graduating to Stable

This enhancement introduced a kubelet-native API for viewing logs of systems running on nodes, removing the need to SSH into the node to view the logs.

For example, to fetch the kubelet logs from a node, you can use:

kubectl get --raw "/api/v1/nodes/node-1/logs?query=kubelet"

ℹ️ Read more in Kubernetes 1.27 - What’s new?

#4205 Support PSI based on cgroupv2

SIG group: sig-node
Stage: Graduating to Stable

PSI (Pressure Stall Information) is a Linux kernel feature introduced in 2018, which measures:

• CPU pressure
• Memory pressure
• I/O pressure

Instead of relying on usage (e.g, CPU usage at 45%), pressure measures how much time tasks spend waiting for a resource, which may be a more accurate metric for some applications.

ℹ️ Remember that to use this feature, you need to be running Linux with PSI support (which should be the case) and enable cgroup v2.

#4265 Add ProcMount option

SIG group: sig-node
Stage: Graduating to Stable

In Linux systems, the /proc filesystem is an interface for kernel data structures that provides information about:

• Processes
• Hardware
• System state
• and more

In Kubernetes, to enforce security, some parts of /proc are masked to prevent accidental exposure of host information. But there are cases where you'd want to unmask certain parts.

One such case is when working in a containers-in-containers scenario, or a container that needs to run another container. This is quite common in CI/CD pipelines that need to build container images within a Kubernetes Pod. In these cases, the parent container needs to write to the nested container's /proc.

Before this feature, users had to run fully privileged containers, which is a much more dangerous scenario.

The feature adds a new ProcMountType string to the securityContext definition, with two possible values: Default and Unmasked.

ℹ️ You will need to use hostUsers: false, or the API server will reject the ProcMountType change.

#4639 VolumeSource: OCI artifact and/or image

SIG group: sig-node
Stage: Graduating to Stable

Kubernetes can now use OCI artifacts and images as volume sources.

A simple use case would be web servers like nginx, where all your website Pods can now use the same base image (adapted to use image volumes) and deploy the configuration and web assets in a separate, minimal image.

⚠️ Allowing the mounting of OCI images in this manner opens the door to potential attack vectors.

✅ Before you enable this feature, strengthen your security policies and don’t allow images to be mounted from untrusted registries or that contain runnable content. Consider blocking Pods that define image volumes.

ℹ️ Read more in Kubernetes 1.35 - What’s new?

#5018 DRA: AdminAccess for ResourceClaims and ResourceClaimTemplates

SIG group: sig-node
Stage: Graduating to Stable

Dynamic Resource Allocation (DRA) is a feature added to Kubernetes to better allocate access to specialized hardware (such as GPUs or FPGAs). In practice, this means gaining privileged access to a device already in use by another user.

This enhancement allows this privileged access without compromising security.

You can request access via a new adminAccess flag on ResourceClaim and ResourceClaimTemplate:

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: admin-resource-claim
  namespace: admin-namespace
spec:
  devices:
    requests:
      - deviceClassName: admin-resource-class
        adminAccess: true

And namespaces must be marked with admin-access to allow for the creation of these claims:

resource.kubernetes.io/admin-access: "true"

#5538 CSI driver opt-in for service account tokens via secrets field

SIG group: sig-storage
Stage: Graduating to Stable

This enhancement introduces a new Secrets field to securely store sensitive data, such as account tokens used to mount cloud buckets. When the serviceAccountTokenInSecrets field is true, the CSI driver will search for the tokens in the Secrets field.

ℹ️ Read more in Kubernetes 1.35 - What’s new?

#5589 Remove gogo protobuf dependency for Kubernetes API types

SIG group: sig-api-machinery
Stage: Major Change to Stable

The Kubernetes API relies on gogo protobuf. However, this library was deprecated in 2021. As this poses a security risk, among other things, work is underway to remove this dependency.

This enhancement focuses on removing these dependencies from the Kubernetes API objects. Instead, the standard golang protobuf library will be used.

ℹ️ For Kubernetes 1.36, work has focused on removing the ProtoMessage method. Check the implementation details in the KEP, or venture into the PR.

Wrapping things up

If you liked this, you might want to check out our previous “What's new in Kubernetes” editions:

• Kubernetes 1.35 - What’s new?
• Kubernetes 1.33 - What’s new?
• Older releases: 1.32, 1.31, 1.30, 1.27, 1.26, 1.25, 1.24, 1.23, 1.22, 1.21, 1.20, 1.19, 1.18, 1.17, 1.16, 1.15, 1.14, 1.13, 1.12.

Get involved with the Kubernetes project:

• Visit the project homepage.
• Check out the Kubernetes project on GitHub.
• Get involved with the Kubernetes community.
• Meet the maintainers on the Kubernetes Slack.
• Follow @Kubernetes.io on X.