Running Kubernetes 1.37 Kubelet Without Root Privileges

Kubernetes normally runs the kubelet and other node components with root privileges on the host. Kubernetes 1.37 changes the security story by moving KubeletInUserNamespace, also known as rootless mode, to Beta.

Rootless mode allows the kubelet, container runtime, CNI plugins, and kube-proxy to run as a non-root host user inside a Linux user namespace. Inside that namespace, the process can have namespace-local root privileges, while the host still sees it as an unprivileged user.

This is useful when you want to reduce the damage a compromised node component could cause to the host. It is also useful for development machines, shared systems, AI sandboxes, and Kubernetes-in-Kubernetes environments.

What Does Rootless Kubelet Actually Mean?

There are two different concepts that are easy to confuse.

A pod can run as a non-root user by using its security context. That changes the identity of processes inside the pod.

Rootless Kubernetes is different. The node components themselves run inside a Linux user namespace.

The basic model looks like this:

Host
|
|-- Normal user: UID 1000
|
`-- Linux user namespace
    |
    |-- kubelet
    |-- container runtime
    |-- CNI
    |-- kube-proxy
    |
    `-- Pods

Inside the user namespace, UID 0 can be used for operations that are allowed by the namespace. Outside the namespace, those operations do not give the process real root privileges on the host.

This distinction matters because rootless mode is an isolation mechanism, not simply a way to change the User= setting in a systemd service.

What Changed in Kubernetes 1.37?

The KubeletInUserNamespace feature graduated to Beta in Kubernetes 1.37.

The feature gate is enabled by default in this release. That does not mean existing Kubernetes nodes automatically become rootless.

The feature allows the kubelet to operate correctly when it is already running inside a user namespace. You still need to create the user namespace and configure the surrounding runtime and host environment.

Kubernetes 1.37 also exposes whether a node is running in a user namespace through the node status. This can help cluster administrators identify rootless nodes and keep workloads that require real host-level privileges away from them.

How Linux User Namespaces Provide the Isolation

A Linux user namespace creates a separate mapping between user IDs inside and outside the namespace.

For example, a host user might be UID 1000:

Host UID 1000
      |
      v
User Namespace UID 0

The process can therefore appear as root inside the namespace without becoming root on the host.

The same concept applies to other namespaces and kernel resources needed by Kubernetes.

This is why rootless Kubernetes needs more than a different Unix account. The environment has to provide the namespace, writable filesystem locations, cgroup support, networking support, and other resources expected by the node components.

Requirements for a Rootless Kubernetes Node

Before testing rootless kubelet, check the host configuration.

1. Linux User Namespaces

The environment must support Linux user namespaces.

The user running Kubernetes also needs subordinate UID and GID ranges. These are normally configured through /etc/subuid and /etc/subgid.

For example:

developer:100000:65536

This gives the user a range of IDs that can be mapped into the namespace.

The exact values depend on the host and distribution.

2. Cgroups v2

Rootless Kubernetes works with cgroups v2.

Check the current cgroup filesystem:

stat -fc %T /sys/fs/cgroup

A cgroups v2 system normally reports:

cgroup2fs

Kubernetes 1.37 also continues its move away from cgroups v1, so using cgroups v2 is the better starting point for a new rootless environment.

3. systemd User Sessions

A rootless environment may need systemd user-session support, especially when cgroups and services are managed through systemd.

Make sure the unprivileged account can maintain its user session independently of an interactive login.

4. Writable Kubernetes Directories

The node components need writable paths inside the user namespace.

Typical paths include:

/etc
/run
/var/log
/var/lib/kubelet
/var/lib/cni
/var/lib/containerd

The exact paths depend on the runtime and how the distribution is assembled.

The important point is that these paths must be writable inside the namespace without giving the host user unrestricted root access.

The Simplest Way to Test Rootless Kubernetes

For most developers, manually building a rootless node is not the best first test.

A local Kubernetes tool such as kind or minikube can run Kubernetes inside a rootless container runtime.

For example, after configuring Rootless Docker, a kind cluster can be created normally:

dockerd-rootless-setuptool.sh install

kind create cluster

The important part is that the container runtime itself is running rootless. Kubernetes then runs inside that user-controlled environment.

Minikube provides a similar approach when used with a rootless Docker or Podman environment.

This setup is much easier to test than manually creating every namespace and mount.

Manually Running the Kubelet in a User Namespace

Manual deployment is primarily useful for Kubernetes distribution developers and people working on node-level infrastructure.

The first step is to create a Linux user namespace.

For example:

unshare --user --map-root-user --mount

This creates a user namespace where the current user can appear as root inside the namespace.

A real Kubernetes setup requires more than this command. Additional namespaces, mounts, networking, cgroups, container runtime configuration, and filesystem permissions must be prepared.

The kubelet also needs access to the expected configuration and state directories.

A simplified layout might look like:

User Namespace
|
|-- /etc
|-- /run
|-- /var/log
|-- /var/lib/kubelet
|-- /var/lib/cni
`-- /var/lib/containerd

These paths should be writable from inside the namespace without modifying host resources outside the intended boundary.

Why the Kubelet Needs Special Handling

The kubelet normally expects to interact with parts of the Linux system that are traditionally controlled by root.

Examples include:

Kernel sysctl values
/dev/kmsg
cgroups
Mount operations
Network namespaces
Container runtime state
Pod filesystem mounts

Rootless mode does not magically give the process unrestricted access to all of these resources.

Instead, the user namespace provides a restricted environment where some operations can succeed with namespace-local privileges.

Kubernetes 1.37 specifically improves kubelet behavior around operations that are expected to fail when running rootless, including certain sysctl changes and access to kernel messages.

Container Runtime Compatibility Matters

The kubelet is only one part of a Kubernetes node.

A rootless configuration also involves the container runtime.

The overall path is roughly:

kubelet
   |
   v
CRI
   |
   v
container runtime
   |
   v
OCI runtime
   |
   v
Linux namespaces and cgroups

If the runtime cannot operate correctly without host root privileges, making only the kubelet unprivileged will not produce a usable rootless node.

This is why supported rootless setups usually configure the entire node environment together.

CNI and CSI Can Be the Hard Part

Networking and storage plugins deserve extra testing.

A CNI plugin may expect operations that require capabilities unavailable in a rootless environment. The same applies to CSI drivers that need host-level access for mounting or device operations.

For example, a CNI component that expects unrestricted access to host networking may not work correctly on a rootless node.

Do not assume that a plugin working on a normal Kubernetes node will automatically work in rootless mode.

Test:

Pod creation
Pod-to-pod networking
Service networking
DNS
Persistent volume mounting
Pod deletion
Container restart
Node restart

This catches compatibility problems much earlier than testing only whether the kubelet starts.

Identifying a Rootless Node

Kubernetes 1.37 exposes information that allows administrators to identify whether a node is running in a user namespace.

This becomes useful when a cluster contains both rootful and rootless nodes.

For example, administrators can use node metadata to separate workloads that require real host privileges from ordinary workloads.

A possible scheduling strategy is:

Rootless nodes
    |
    |-- normal application workloads
    |-- development workloads
    `-- isolated workloads

Rootful nodes
    |
    |-- privileged system workloads
    |-- host-level networking
    `-- workloads requiring real host access

This is safer than assuming every workload can run on every node.

Common Problems

Kubelet Starts but Pods Do Not Start

Check the container runtime first.

The kubelet can be healthy while the runtime fails to create containers because it cannot perform a required operation in the rootless environment.

Networking Fails

Check the CNI plugin.

Look for assumptions about host networking, network namespaces, iptables, kernel capabilities, and writable networking state.

Persistent Volumes Fail

Storage is another common compatibility boundary.

Check whether the CSI driver requires privileged host operations. Rootless kubelet does not remove the underlying requirements of a storage driver.

Cgroup Errors Appear

Verify that the host uses cgroups v2 and that the user session has the required delegation.

Cgroup configuration is one of the first things to check when containers start but resource management behaves incorrectly.

Permission Errors Appear in `/var/lib`

Do not solve every permission error by making the entire host directory world-writable.

Instead, identify which directory must be writable inside the user namespace and configure the namespace or runtime accordingly.

That keeps the host boundary intact.

Rootless Kubelet vs Traditional Kubelet

Area	Traditional Node	Rootless Node
Host identity	Root	Unprivileged user
User namespace	Usually not required	Required
Kubelet	Host root	User namespace
Container runtime	Usually root	Rootless-compatible runtime
Host isolation	Lower	Stronger boundary
CNI compatibility	Broad	Requires validation
CSI compatibility	Broad	Requires validation
Setup complexity	Lower	Higher
Best fit	General production nodes	Security-sensitive or specialized environments

The main trade-off is straightforward: rootless mode reduces host privilege, but the environment has more compatibility requirements.

Best Practices

Start with a Supported Rootless Runtime

For a first implementation, use a rootless runtime and a Kubernetes tool that already supports that model. This removes much of the manual namespace setup.

Test the Node Components Together

Do not test only the kubelet.

Validate:

kubelet
CRI
container runtime
OCI runtime
CNI
kube-proxy
storage integration

A rootless node is an entire execution environment.

Label or Taint Specialized Nodes

If your cluster contains rootless and rootful nodes, make the distinction visible to the scheduler.

For example:

kubectl label node worker-01 node-security=rootless

You can then use node affinity or taints and tolerations for workloads with specific requirements.

Keep Traditional Hardening

User namespaces are not a replacement for other security controls.

Continue using:

Seccomp
AppArmor or SELinux where appropriate
Minimal container capabilities
Network policies
Regular patching
Least-privilege service accounts

A user namespace helps limit the impact of a compromised component, but it does not protect against every kernel vulnerability.

Advantages and Disadvantages

Advantages

Reduces host-level root privileges for Kubernetes node components.
Limits the potential impact of some container or node-component compromises.
Works well for shared development environments.
Useful for AI sandboxes where generated code should not receive unrestricted host access.
Enables interesting Kubernetes-in-Kubernetes scenarios.
Provides another isolation layer for specialized workloads.

Disadvantages

Requires a correctly configured Linux environment.
Cgroups and user namespace configuration add operational complexity.
Some CNI and CSI implementations may not be compatible.
Host-level operations that depend on real root privileges may fail.
Troubleshooting is more involved than with a traditional node.
It should not be treated as a universal replacement for rootful Kubernetes nodes.

When Should You Use Rootless Kubernetes?

Rootless mode makes the most sense when reducing host privilege is an explicit requirement.

Good candidates include:

Developer workstations
Shared Linux machines
HPC environments
AI coding sandboxes
Security-sensitive test clusters
Nested Kubernetes environments
Experimental Kubernetes infrastructure

For a standard production cluster where existing networking, storage, monitoring, and security components all depend on traditional host privileges, migrating every node to rootless mode should be treated as a compatibility project rather than a simple kubelet configuration change.

Conclusion

Kubernetes 1.37 makes running node components without host root privileges more practical by graduating KubeletInUserNamespace to Beta.

The important detail is that rootless mode is an environment-level change. The kubelet, runtime, networking components, and supporting Linux configuration all need to work within the user namespace.

For developers, the safest starting point is a supported rootless container runtime with a tool such as kind or minikube. For Kubernetes distribution developers, manually constructing the user namespace provides more control but also exposes the compatibility work involved.

The result is a Kubernetes node with a smaller host privilege boundary, which can be valuable when the cost of a compromised node component needs to be limited.

What Does Rootless Kubelet Actually Mean?

What Changed in Kubernetes 1.37?

How Linux User Namespaces Provide the Isolation

Requirements for a Rootless Kubernetes Node

1. Linux User Namespaces

2. Cgroups v2

3. systemd User Sessions

4. Writable Kubernetes Directories

The Simplest Way to Test Rootless Kubernetes

Manually Running the Kubelet in a User Namespace

Why the Kubelet Needs Special Handling

Container Runtime Compatibility Matters

CNI and CSI Can Be the Hard Part

Identifying a Rootless Node

Common Problems

Kubelet Starts but Pods Do Not Start

Networking Fails

Persistent Volumes Fail

Cgroup Errors Appear

Permission Errors Appear in /var/lib

Rootless Kubelet vs Traditional Kubelet

Best Practices

Start with a Supported Rootless Runtime

Test the Node Components Together

Label or Taint Specialized Nodes

Keep Traditional Hardening

Advantages and Disadvantages

Advantages

Disadvantages

When Should You Use Rootless Kubernetes?

Conclusion

Permission Errors Appear in `/var/lib`