KEP-5607: Allow hostNetwork pods to use user namespaces #5608
Conversation
HirazawaUi
commented
Oct 3, 2025
HirazawaUi
commented
- One-line PR description: Allow hostNetwork pods to use user namespaces
- Issue link: Allow HostNetwork Pods to Use User Namespaces #5607
- Other comments:
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
kind/kep
HirazawaUi
force-pushed
the
kep-5607
branch
2 times, most recently
from
6252f70 to
f4441d3
Compare
| When the `UserNamespacesHostNetworkSupport` feature gate is enabled, we will relax this validation check. | ||
| The kube-apiserver will accept such a Pod spec and pass it on to the kubelet. | ||
| At this point, the responsibility for successfully creating and running the Pod shifts to the container runtime. | ||
| If the low-level container runtime (e.g., containerd/runc) does not support this combination, the pod will remain stuck in the `ContainerCreating` state and report an exception event, which is the expected behavior. |
There was a problem hiding this comment.
If we go with this proposal, we should include making it work with containers/crio/runc.
There was a problem hiding this comment.
containerd needs changes for this, I think runc too. I'm unsure about crio and crun. @giuseppe ?
There was a problem hiding this comment.
crun supports it. I am not sure about CRI-O but I don't see any explicit check to prevent that combination
There was a problem hiding this comment.
This has been added as a graduation requirement for the beta phase.
| ### User Stories (Optional) | ||
|
|
||
| #### Story 1 | ||
| As a cluster administrator, I want to enable user namespaces for my control plane static Pods (e.g., kube-apiserver, kube-controller-manager) to follow the principle of least privilege and reduce the attack surface. These Pods need to use hostNetwork to interact correctly with the cluster network. By enabling the new feature gate, I can add a critical layer of security isolation to these vital components without changing their networking model. |
There was a problem hiding this comment.
There was a problem hiding this comment.
Yeap, this will need quite some documentation. To make sure users understand you probably can't bind on privileged ports even if you have cap whatever or maybe even the sysctl to change the privileged port range is ineffective too.
But LGTM
There was a problem hiding this comment.
I assume that capabilities such as CAP_NET_RAW, CAP_NET_ADMIN, and CAP_NET_BIND_SERVICE remain restricted. I have also added this as a graduation requirement for the beta phase in the KEP.
Please correct me if I'm wrong, as I am not deeply familiar with this area.
There was a problem hiding this comment.
SGTM. I'd say let's document this in alpha, but I don't oppose as doing it for beta. I don't see why to postpone it :)
There was a problem hiding this comment.
During the alpha stage, this feature is not accessible to users, as we are still awaiting runtime support across the board. Additionally, we need to wait until runtime support is in place to finalize the scope of this feature :)
HirazawaUi
force-pushed
the
kep-5607
branch
4 times, most recently
from
6fcfeb6 to
19be9bb
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: HirazawaUi The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
