KEP-5607: Allow hostNetwork pods to use user namespaces #5608

HirazawaUi · 2025-10-03T16:26:43Z

One-line PR description: Allow hostNetwork pods to use user namespaces

Issue link: Allow HostNetwork Pods to Use User Namespaces #5607

Other comments:

mrunalp · 2025-10-06T17:55:15Z

keps/sig-node/5607-hostnetwork-userns/README.md

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


If we go with this proposal, we should include making it work with containers/crio/runc.

containerd needs changes for this, I think runc too. I'm unsure about crio and crun. @giuseppe ?

crun supports it. I am not sure about CRI-O but I don't see any explicit check to prevent that combination

This has been added as a graduation requirement for the beta phase.

mrunalp · 2025-10-06T17:57:19Z

keps/sig-node/5607-hostnetwork-userns/README.md

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


We need to be clear about what is possible with such a combination. For e.g. this may work for just listening on host network but will probably fail even if the pod has admin privileges and tries to make changes that are prevented by the user namespace.

cc: @rata @giuseppe

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

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.

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 :)

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 :)

keps/sig-node/5607-hostnetwork-userns/README.md

keps/prod-readiness/sig-node/5607.yml

keps/sig-node/5607-hostnetwork-userns/README.md

wojtek-t · 2025-10-15T06:36:57Z

This looks fine for Alpha from PRR perspective. Thanks!

/approve PRR

aojea · 2025-10-15T08:48:45Z

keps/sig-node/5607-hostnetwork-userns/README.md

+#### GA
+
+- The feature has been stable in Beta for at least 2 Kubernetes releases.
+- Multiple major container runtimes support the feature.


One last question, in GA we completely disable the feature gate , so if a runtime does not support it the pod will be fail, is that ok?

Users can optionally enable this feature. Taking the UserNamespacesSupport feature it relies on as an example, if the container runtime does not support this UserNamespacesSupport, the pod will similarly remain stuck in the ContainerCreating state. :)

ok, meanwhile we are fine with this, I just want to avoid we end using the feature gate as a feature flag , similar on what happened with the swap feature

yeah I am fine with this. We may wait to GA until e.g. all containerd versions k8s chooses to support support this feature (similar to cgroup driver from CRI, or CRI stats)

HirazawaUi · 2025-10-16T00:57:51Z

/assign @mrunalp for approval

keps/sig-node/5607-hostnetwork-userns/kep.yaml

SergeyKanzhelev

/lgtm
/approve

/assign @mrunalp

k8s-ci-robot · 2025-10-16T16:01:21Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: HirazawaUi, mrunalp, SergeyKanzhelev, wojtek-t

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~keps/prod-readiness/OWNERS~~ [wojtek-t]
~~keps/sig-node/OWNERS~~ [mrunalp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

SergeyKanzhelev · 2025-10-16T16:15:11Z

/lgtm

We have a beta graduation criteria to list all limitations. We will need to decide at that stage if there some additional things will be needed to help customers to not break things

haircommander · 2025-10-16T16:20:16Z

keps/sig-node/5607-hostnetwork-userns/README.md

+
+### Risks and Mitigations
+
+If either the container runtime or the underlying container runtime does not support this feature, the container will fail to be created. To mitigate this issue, we will keep this feature in the alpha stage until mainstream container runtimes (containerd/runc) and mainstream underlying container runtimes (runc/crun) both support it, before promoting it to beta.


I like to use CRI implementations (containerd/crio) to resolve ambiguity

Ah, yes, that was a typo. I'll fix it in the next PR.

Experimenting in alpha sounds like a good approach here. We need to clearly articulate limitations and supported scenarios. Hopefully we will be able to avoid confusion with customer, maybe we will need some new API or API validaiton.

We could add tests based on "error" scenarios during the alpha phase, but there's one issue with alpha-stage testing: if the container runtime supports this behavior in a future version, those tests designed for "error" scenarios would fail.

For Containerd make sure to follow the process https://containerd.io/keps/ and coordinate the right approach here with the runtime maintainers

Got it, thanks for the reminder! :)

haircommander · 2025-10-16T16:21:38Z

keps/sig-node/5607-hostnetwork-userns/README.md

+## Design Details
+
+The core design change is very simple: in the apiserver's Pod validation logic, locate the code block that prevents the `hostNetwork: true` and `hostUsers: false` combination, and wrap it in a conditional that only executes the validation if the `UserNamespacesHostNetworkSupport` feature gate is disabled.
+


hm this doesn't actually include the changes to crio/containerd/runc/crun . it's confusing because some parts of the KEP mark it as a beta requirement, but this section doesn't touch it at all

Since I haven't implemented it in the container runtime and the underlying container runtime yet, I haven't included the implementation details for now. If possible, I think we can add it during the beta phase.

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Oct 3, 2025

k8s-ci-robot requested review from derekwaynecarr and mrunalp October 3, 2025 16:26

k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/node Categorizes an issue or PR as relevant to SIG Node. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Oct 3, 2025

HirazawaUi mentioned this pull request Oct 3, 2025

Allow HostNetwork Pods to Use User Namespaces #5607

Open

4 tasks

HirazawaUi force-pushed the kep-5607 branch 2 times, most recently from 6252f70 to f4441d3 Compare October 3, 2025 16:41

neolit123 mentioned this pull request Oct 4, 2025

run control-plane as non-root kubernetes/kubeadm#2473

Open

16 tasks

mrunalp reviewed Oct 6, 2025

View reviewed changes

rata reviewed Oct 7, 2025

View reviewed changes

keps/sig-node/5607-hostnetwork-userns/README.md Outdated Show resolved Hide resolved

HirazawaUi force-pushed the kep-5607 branch 4 times, most recently from 6fcfeb6 to 19be9bb Compare October 8, 2025 09:42

wojtek-t reviewed Oct 8, 2025

View reviewed changes

keps/prod-readiness/sig-node/5607.yml Outdated Show resolved Hide resolved

wojtek-t self-assigned this Oct 8, 2025

HirazawaUi force-pushed the kep-5607 branch from 19be9bb to c4ad6c5 Compare October 8, 2025 13:32

wojtek-t reviewed Oct 13, 2025

View reviewed changes

HirazawaUi force-pushed the kep-5607 branch 2 times, most recently from e1b7b09 to 3597a1c Compare October 13, 2025 14:25

aojea reviewed Oct 13, 2025

View reviewed changes

keps/sig-node/5607-hostnetwork-userns/README.md Show resolved Hide resolved

aojea reviewed Oct 13, 2025

View reviewed changes

keps/sig-node/5607-hostnetwork-userns/README.md Outdated Show resolved Hide resolved

wojtek-t reviewed Oct 14, 2025

View reviewed changes

HirazawaUi force-pushed the kep-5607 branch 3 times, most recently from f71fe90 to ced6f5b Compare October 15, 2025 00:13

aojea reviewed Oct 15, 2025

View reviewed changes

SergeyKanzhelev reviewed Oct 16, 2025

View reviewed changes

keps/sig-node/5607-hostnetwork-userns/kep.yaml Outdated Show resolved Hide resolved

SergeyKanzhelev approved these changes Oct 16, 2025

View reviewed changes

k8s-ci-robot assigned mrunalp and SergeyKanzhelev Oct 16, 2025

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 16, 2025

Allow hostNetwork pods to use user namespaces

d6bae64

HirazawaUi force-pushed the kep-5607 branch from ced6f5b to d6bae64 Compare October 16, 2025 07:30

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 16, 2025

mrunalp approved these changes Oct 16, 2025

View reviewed changes

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 16, 2025

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 16, 2025

haircommander reviewed Oct 16, 2025

View reviewed changes

k8s-ci-robot merged commit 5002b73 into kubernetes:master Oct 16, 2025
4 checks passed

k8s-ci-robot added this to the v1.35 milestone Oct 16, 2025

haircommander reviewed Oct 16, 2025

View reviewed changes


		### Risks and Mitigations

		If either the container runtime or the underlying container runtime does not support this feature, the container will fail to be created. To mitigate this issue, we will keep this feature in the alpha stage until mainstream container runtimes (containerd/runc) and mainstream underlying container runtimes (runc/crun) both support it, before promoting it to beta.

		## Design Details

		The core design change is very simple: in the apiserver's Pod validation logic, locate the code block that prevents the `hostNetwork: true` and `hostUsers: false` combination, and wrap it in a conditional that only executes the validation if the `UserNamespacesHostNetworkSupport` feature gate is disabled.

KEP-5607: Allow hostNetwork pods to use user namespaces #5608

KEP-5607: Allow hostNetwork pods to use user namespaces #5608

Uh oh!

Conversation

HirazawaUi commented Oct 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wojtek-t commented Oct 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HirazawaUi Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HirazawaUi commented Oct 16, 2025

Uh oh!

Uh oh!

SergeyKanzhelev left a comment

Choose a reason for hiding this comment

Uh oh!

k8s-ci-robot commented Oct 16, 2025

Uh oh!

SergeyKanzhelev commented Oct 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SergeyKanzhelev Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

HirazawaUi Oct 15, 2025 •

edited

Loading

SergeyKanzhelev Oct 17, 2025 •

edited

Loading