< back to blog

Kubernetes 1.37 - New security features

Victor Jimenez Cerrada
Kubernetes 1.37 - New security features
Published by:
Victor Jimenez Cerrada
Kubernetes 1.37 - New security features
@
linkedin
Kubernetes 1.37 - New security features
Published:
August 26, 2026
Table of contents
falco feeds by sysdig

Falco Feeds extends the power of Falco by giving open source-focused companies access to expert-written rules that are continuously updated as new threats are discovered.

learn more
Green background with a circular icon on the left and three bullet points listing: Automatically detect threats, Eliminate rule maintenance, Stay compliant, with three black and white cursor arrows pointing at the text.

Kubernetes 1.37 has just been released, bringing 67 enhancements.

In terms of security, we’ve identified 19 changes with security implications spanning new security features to mount volumes, improvements on snapshots, authentication by default on webhooks, and more.

Let’s dig in!

Security changes in Kubernetes 1.37 that may break things

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

With this optimization, it’s a bit easier for cluster administrators to strengthen their clusters with SELinux.

⚠️ In Kubernetes 1.37, SELinuxMount, the last bit of this enhancement, graduates to stable, meaning that this optimization will be applied to all eligible volumes. This may cause issues in rare cases where Pods with different SELinux labels, or with different privilege levels, share the same volume.

ℹ️ Read more about the SELinuxMount breaking change.

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

#5343 Make nftables the default kube-proxy backend

SIG group: sig-network
#5343 Stage: Net New to Alpha

Since 1.33, the nftables backend mode for kube-proxy (#3866) has been considered stable and will be the default in 1.40. In 1.37, users will start seeing a warning if they are currently using iptables as a default.

⚠️ If you are making the transition now, make sure your security tools are covering the new config files.

Related: Also, in this release the ipvs mode is taking its first steps towards deprecation (#5495).

#140226 Kubelet: Static Pods can no longer reference Secrets or ConfigMaps

A bug where static Pods could reference Secrets or ConfigMaps is now fixed, and the related PreventStaticPodAPIReferences feature gate has been removed.

Exposed info in new APIs

As usual, this new Kubernetes release brings several enhancements that expose new data to the API. To name a few:

This data is usually meant for cluster administrators to help monitor the health of the cluster, make decisions, or troubleshoot issues.

⚠️ However, this extra data may also help attackers to understand your infrastructure better.

✅ Review who has access to the API to ensure they are accessing only the data they need.

Net new security enhancements in Kubernetes 1.37

#4939 Support TLS credentials in gRPC probe

SIG group: sig-node
Stage: Net New to Alpha
Feature Gate: GRPCContainerProbeTLS Default: false

Your Kubernetes 1.37 cluster will be able to probe gRPC health servers that require TLS natively. Before, you would need to work around this by using an exec probe that would execute a command.

ℹ️ Use the new mode field:

livenessProbe:
  grpc:
    port: 8443
    mode: TLS

#5502 Add stickyBit support for emptydir volumes

SIG group: sig-storage
Stage: Net New to Alpha
Feature Gate: FOO Default: false

This new enhancement allows you to create an EmptyDirVolumeSource with a permission mode between 0000 and 01777, instead of the default 0777.

ℹ️ Use the new mode field:

volumes:
  - name: app-data
    emptyDir:
      mode: 01777

#5823 Pod-level checkpoint/restore

SIG group: sig-node
Stage: Net New to Alpha
Feature Gate: PodLevelCheckpointRestore Default: false

The current Kubelet Checkpoint API can create stateful copies of a running container. However, Kubernetes workloads are a combination of many containers.

Now, cluster administrators can create and restore checkpoints at a Pod level.

This can be useful for speeding up startup. The intended use is first to create checkpoints once the Pod has loaded, then restore it when the Pod is needed again instead of doing a cold start.

Another use case, and the reason why we included this, is recovering a cluster faster from a failure. Recovery time is often a forgotten area of security, but it’s an important part of resilience.

ℹ️ You can set up PodCheckpoints to be created once certain conditions are met:

apiVersion: checkpoint.k8s.io/v1alpha1
kind: PodCheckpoint
metadata:
  name: myapp-snapshot-01
  namespace: team-a
status:
  nodeName: node-1
  checkpointLocation:
    type: NodeLocal
    nodeLocal:
      path: checkpoint-myapp_team-a-2026-05-28T10:14:22Z
  checkpointedPodTemplate:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: registry.example.com/myapp:v1.4.0
      # ...scheduling constraints, resources, and security contexts as captured.
  conditions:
  - type: Ready
    status: "True"
    reason: CheckpointCompleted
    message: "checkpoint archive written successfully"
    observedGeneration: 1

Then, use them in Pods. Notice the restoreFrom field:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-restored
  namespace: team-a
spec:
  restoreFrom: myapp-snapshot-01
  # No nodeName: admission injects a required node affinity for the checkpoint's
  # node and the scheduler binds the Pod there.
  containers:
  - name: app
    image: registry.example.com/myapp:v1.4.0
    # ...rest of spec must match the spec inside myapp-snapshot-01

#5855 Add bind mount options (noexec, nodev, nosuid) support on volumeMounts

SIG group: sig-node
Stage: Net New to Alpha
Feature Gate: VolumeBindMountOptions Default: false

This enhancement introduces a new bindMountOptions field on volumeMounts to define security-related flags such as noexec, nodev, or nosuid.

ℹ️ For example, you could add the noexec flag to a volume mounted on /tmp to stop attackers from running chmod +x to make executable the malicious files they just downloaded (a common technique).

volumes:
  - name: tmp
    emptyDir: {}
containers:
  - name: app
    volumeMounts:
      - name: tmp
        mountPath: /tmp
        bindMountOptions: [noexec, nosuid]

#5936 Add user fields to atomic write volumes

SIG group: sig-storage
Stage: Net New to Alpha
Feature Gate: AtomicWriteVolumeUserFields Default: false

You can now restrict the ownership of atomic write volumes’ files like those from ConfigMap, Secret, DownwardAPI, and Projected volumes.

This wasn’t possible in clusters implementing restricted pod security and required high-maintenance workarounds for the rest.

ℹ️ Notice the user and defaultUser fields:

volumes:
- name: volA
  configMap:
    defaultUser: 1000
    name: cm1
    items:
    - key: foo // Owner=defaultUser
      path: foo
    - key: bar // Owner=user
      path: bar
      user: 1001

#5943 Topology for volume snapshots

SIG group: sig-storage
Stage: Net New to Alpha
Feature Gate: VolumeSnapshotTopology Default: false

Following on the disaster recovery theme, administrators can now include topology data to volume snapshots.

This data can be used both to guide where snapshots are stored so they align with your disaster recovery requirements, and to guide where they are restored so recovery is faster.

ℹ️ Topology information is defined on the allowedTopologies field of a VolumeSnapshotClass:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc
driver: ebs.csi.aws.com
deletionPolicy: Delete
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/region
        values:
          - us-west-2

And then is available on the Node Affinity field of a VolumeSnapshotContent:

Name:         snapcontent-123-456-789
[…]
Spec:
[…]
  Source Volume Mode:          Filesystem
  Volume Snapshot Class Name:  csi-aws-vsc
[…]
  Node Affinity:
    - matchLabelExpressions:
        - key: topology.kubernetes.io/region
          values:
            - us-west-2
        - key: topology.kubernetes.io/zone
          values:
            - us-west-2a
            - us-west-2b
Status:
  Creation Time:    1234567890000000
  Ready To Use:     true
  Restore Size:     4294967296
  Snapshot Handle:  snap-123456789
Events:             <none>

#6060 API server authentication to webhooks

SIG group: sig-auth
Stage: Net New to Alpha
Feature Gate: APIServerAuthenticationToWebhooks Default: false

Up until now, kube-apiserver didn’t authenticate to admission webhooks by default. An attacker with network access could probe webhooks for policy information, trigger unintended side effects, or exploit the webhook’s permissions.

This enhancement not only enables this authentication by default (when the feature gate is enabled), but also uses the TokenRequest API so implementing this authentication does not require manual steps.

ℹ️ Check the KEP for implementation details on the JWT payloads and the authentication flows.

Kubernetes 1.37 will enable these security features by default

#2033 Kubelet-in-userns, aka rootless mode

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

This enhancement allows you to run the kubelet as a non-root user (in a user namespace), protecting the host from container-breakout vulnerabilities.

It’s been in Alpha since Kubernetes 1.22, and in 1.37 some cleanup work has been done:

  • You can check if a node is running in a user namespace by checking the runningInUserNamespace field in kubectl get nodes -o yaml.
  • Kubernetes CI/CD testing now runs on a rootless cluster.

ℹ️ Check the KEP for extra notes, constraints, and caveats.

#5541 Report last used time on a PVC

SIG group: sig-storage
Stage: Graduated to Beta
Feature Gate: PersistentVolumeClaimUnusedSinceTime Default: true

A new condition type, Unused, in the PersistentVolumeClaim status conditions helps cluster administrators identify unused PVCs. Cluster administrators can implement cleanup policies to remove these PVCs, which reduces the attack surface of the cluster.

After one release in Alpha, this enhancement graduates to Beta without major functional changes.

#5793 Manifest-based admission control config

SIG group: sig-api-machinery
Stage: Graduating to Beta
Feature Gate: ManifestBasedAdmissionControlConfig Default: true
Feature Gate: ExcludeAdmissionWebhookVirtualResources Default: true

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

In Kubernetes 1.37, admission webhooks also exclude non-persisted (virtual) authentication and authorization resources, such as TokenReview and SubjectAccessReview. This mirrors the behavior from ValidatingAdmissionPolicy or MutatingAdmissionPolicy, and prevents webhooks from blocking the cluster's own authentication and authorization requests.

✅ Enable the AdmissionConfiguration file by adding:

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

ℹ️ Read more in Kubernetes 1.36 - New security features

Kubernetes 1.37 changes in other existing features

#4412 Projected service account tokens for Kubelet image credential providers

SIG group: sig-auth
Stage: Major Change to Beta
Feature Gate (kubelet): KubeletServiceAccountTokenForCredentialProviders Default: true
Feature Gate (kube-apiserver): ServiceAccountNodeAudienceRestriction Default: true

This enhancement allows Kubernetes Service Accounts (KASs) to use short-lived credentials for image pulls. Compared to long-lived credentials, these ephemeral ones simplify secret management for developers and admins while also limiting the time a bad actor can use them if they are leaked.

You can configure a provider like so:

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
  - name: acr-credential-provider
    matchImages:
      - "*.registry.io/*"
    defaultCacheDuration: "10m"
    apiVersion: credentialprovider.kubelet.k8s.io/v1
    tokenAttributes:
      serviceAccountTokenAudience: my-audience
      cacheType: Token
      # Only invoke the plugin if the pod has a service account
      requireServiceAccount: true
      # Invoke the plugin if all these annotations are present, and pass the values.
      requiredServiceAccountAnnotationKeys:
      - domain.io/identity-id
      - domain.io/identity-type
      # If present, these annotations are also passed.
      optionalServiceAccountAnnotationKeys:
      - domain.io/some-optional-annotation
      - domain.io/annotation-that-does-not-exist

ℹ️ In Kubernetes 1.37, new caching options have been implemented to optimize the fetching of multiple images.

✅ Replace long-lived credentials with short-lived ones whenever possible.

#3257 ClusterTrustBundles (previously Trust Anchor Sets)

SIG group: sig-auth
Stage: Graduating to Stable

The ClusterTrustBundle objects are cluster-scoped containers for X.509 trust anchors (root certificates). Pods can mount these objects using the clusterTrustBundle projection to validate signers.

ℹ️ Learn more in the ClusterTrustBundle documentation.

#4317 Pod certificates

SIG group: sig-auth
Stage: Graduating to Stable

This enhancement allows you to use the certificate signing request API to provide certificates for your workloads.

ℹ️ Read more in Kubernetes 1.36 - New security features

#4762 Allows setting any FQDN as the pod's hostname

SIG group: sig-network
Stage: Graduating to Stable

With HostnameOverride, developers can set an arbitrary Fully Qualified Domain Name (FQDN) as the hostname of a pod.

This is useful for older services, like the Kerberos replication daemon (kpropd), which need to handle hostname resolution for authentication accurately.

#5295 KYAML

SIG group: sig-cli
Stage: Graduating to Stable

KYAML is a safer and less ambiguous subset of YAML designed for Kubernetes config files. As a subset, it was already supported as an input. However, this enhancement adds the option to request outputs in KYAML in addition to json or yaml.

✅ Use KYAML when possible to avoid misconfigurations driven by ambiguous values.

ℹ️ Keep an eye on the Kubernetes blog; an upcoming post will cover KYAML and the ambiguities it solves in detail.

Wrapping things up

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

Get involved with the Kubernetes project:

About the author

Kubernetes & Container Security
featured resources

Test drive the right way to defend the cloud
with a security expert

GET A DEMO