KEP-127: Support userns in stateless pods with idmap mounts

[rata]

• One-line PR description: Change the implementation to rely on idmap mounts. This simplifies the implementation in kubernetes and container runtimes and removes several limitations we hit before

• Issue link: Support User Namespaces in pods #127

• Other comments: We did a prototype implementation on container runtimes (containerd, runc, CRIO, crun) with @giuseppe and we didn't find anything unexpected.

The change to make this KEP about only stateless pods was discussed last year in sig-node and when we asked for an exception for the 1.25 release (https://groups.google.com/g/kubernetes-sig-release/c/ASWlhA-tIxE/m/mMWeXx_kAwAJ). The first commits of this PR just update the KEP to be about stateless pods, as was agreed, the rest of the commits re-work the KEP to rely on idmap mounts.

cc @thockin @mrunalp @derekwaynecarr @SergeyKanzhelev

[remram44]

If seems that you have removed the description of the phases but you still reference "phase 2" and "phase 3"?

[rata]

@remram44 Yes, phase 2 and 3 were about stateful workloads. As this KEP is now about stateless pods, those sections don't fit in this KEP anymore. This was decided last year and a reason on why an exception was granted for this KEP last year (https://groups.google.com/g/kubernetes-sig-release/c/ASWlhA-tIxE/m/mMWeXx_kAwAJ).

Added this as a clarification on the PR description. Thanks!

[remram44]

@rata What I mean is that you removed all definitions of the phases but you kept references to those phases like "See phase 3 for limitations" (line 129) and "Phase 2 (support for pods with volumes) is out of scope" (line 1062). I think if you are going to refer to those phases they should be described, in this document or in another.

[rata]

@remram44 oh, thanks. Removed those references to phases too! :)

@thockin @mrunalp fixed my brain fart in the example. PTAL

[rata]

@mrunalp @thockin I think all comments are addressed, PTAL. Thanks!

[marosset]

@rata please update the milestones in https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/kep.yaml as part of the PR too.

[rata]

@marosset thanks, will do it. How is it, though? Should I update latest-milestone only, and keep the alpha: "v1.25" as that is when it was first merged? That is my understanding from the template, so will do that. But if you can confirm, it will be great :)

[marosset]

@marosset thanks, will do it. How is it, though? Should I update latest-milestone only, and keep the alpha: "v1.25" as that is when it was first merged? That is my understanding from the template, so will do that. But if you can confirm, it will be great :)

Did any code merge for this in v1.25?
If the enhancement is targeting alpha in v1.27 (which it looks like it is but I didn't look too close) then update the alpha milestone to v1.27 too please

[rata]

@marosset thanks, will do it. How is it, though? Should I update latest-milestone only, and keep the alpha: "v1.25" as that is when it was first merged? That is my understanding from the template, so will do that. But if you can confirm, it will be great :)

Did any code merge for this in v1.25?

Yes, we did merge support for userns in 1.25 (without idmap mounts)

If the enhancement is targeting alpha in v1.27 (which it looks like it is but I didn't look too close) then update the alpha milestone to v1.27 too please

It targets alpha this re-work. So, I guess I should leave it as it is now, then :)

[mrunalp]

/lgtm
/approve

[rata]

@dchen1107 This is the userns PR we talked about in the sig-node meeting. PTAL, thanks! :)

[dchen1107]

/approve
/label leads-opted-in

[k8s-ci-robot]

@dchen1107: The label(s) /label leads-opted-in cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, lead-opted-in, tracked/no, tracked/out-of-tree, tracked/yes. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/approve
/label leads-opted-in

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dchen1107, mrunalp, rata

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/sig-node/OWNERS [dchen1107]

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

[wojtek-t]

FWIW - this LGTM for a second alpha from PRR perspective.