Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for user namespaces #127

Open
4 tasks
derekwaynecarr opened this issue Oct 10, 2016 · 132 comments
Open
4 tasks

Add support for user namespaces #127

derekwaynecarr opened this issue Oct 10, 2016 · 132 comments
Assignees
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. sig/node Categorizes an issue or PR as relevant to SIG Node. stage/alpha Denotes an issue tracking an enhancement targeted for Alpha status tracked/no Denotes an enhancement issue is NOT actively being tracked by the Release Team
Milestone

Comments

@derekwaynecarr
Copy link
Member

derekwaynecarr commented Oct 10, 2016

Enhancement Description

  • One-line enhancement description (can be used as a release note): Add support for user namespaces in pods
  • Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md
  • Discussion Link: This was discussed in several sig-node meetings, most notable Nov 2 2021 and in this PR, that feedback was incorporated already by this KEP is taking: keps/127: Support User Namespaces #2101.
  • Primary contact (assignee): @rata @giuseppe
  • Responsible SIGs: sig-node
  • Enhancement target (which target equals to which milestone):
    • Alpha release target (x.y): 1.25
    • Beta release target (x.y):
    • Stable release target (x.y):
  • Alpha
    • KEP (k/enhancements) update PR(s):
    • Code (k/k) update PR(s):
    • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

@derekwaynecarr
Copy link
Member Author

derekwaynecarr commented Oct 10, 2016

This work is being done by @pweil- and is reviewed by @derekwaynecarr, it is sponsored by @kubernetes/sig-node

@idvoretskyi idvoretskyi modified the milestone: v1.5 Oct 11, 2016
@idvoretskyi idvoretskyi added the sig/node Categorizes an issue or PR as relevant to SIG Node. label Oct 12, 2016
@mdshuai
Copy link
Contributor

mdshuai commented Oct 26, 2016

@derekwaynecarr Could you help create a user story card for this feature?

@idvoretskyi
Copy link
Member

idvoretskyi commented Nov 15, 2016

@derekwaynecarr can you confirm that this feature targets alpha for 1.5?

@pweil-
Copy link
Member

pweil- commented Nov 16, 2016

@derekwaynecarr can you confirm that this feature targets alpha for 1.5?

Yes, this feature is experimental only so it would be considered alpha.

@idvoretskyi
Copy link
Member

idvoretskyi commented Dec 13, 2016

@derekwaynecarr @pweil- can you confirm that this item targets beta in 1.6?

@adelton
Copy link

adelton commented Nov 14, 2017

@derekwaynecarr, the proposal kubernetes/kubernetes#34569 was closed by bot due to inactivity.

@pweil-, in kubernetes/kubernetes#34569 (comment) you've proposed the approach pweil-/kubernetes@16f29eb which changes the group of /var/lib/kubelet/pods to the remapped root group. Do I understand it correctly that this is currently not tracked in any pull request?

@adelton
Copy link

adelton commented Nov 14, 2017

@pweil-, I also wonder if similar to docker's /var/lib/docker/<uid>.<gid> approach when --userns-remap is used, it might make sense to use /var/lib/kubelet/pods-<uid>.<gid> and just chown/chgroup everything in those subdirectories to the remapped <uid>.<gid>. Why did you opt for just the chgrp and not the full chown?

@pweil-
Copy link
Member

pweil- commented Nov 14, 2017

@adelton in the end, I think having this be transparent to Kubernetes is the right approach. Whether that be something like shiftfs or implementation in the CRI (moby/moby#28593). You are correct that my existing proposal is not currently tracked in an open PR anymore.

The reasoning behind using the chgrp was to follow our fsgroup strategy where we just ensure group access instead of uid access.

@adelton
Copy link

adelton commented Nov 14, 2017

Thanks @pweil-.

When you say transparent, you mean that nothing should be needed to be added to code or to configuration on Kubernetes' side to allow running under docker with userns-remap?

As for the fsgroup strategy, do you mean https://kubernetes.io/docs/concepts/policy/pod-security-policy/#fsgroup or some generic methodology within Kubernetes?

I have now filed kubernetes/kubernetes#55707 as an alternative approach where I make the remapped uid/gid an explicit option, and use those values to chown/chgrp the necessary directories.

@pweil-
Copy link
Member

pweil- commented Nov 14, 2017

When you say transparent, you mean that nothing should be needed to be added to code or to configuration on Kubernetes' side to allow running under docker with userns-remap?

that would be ideal. Whether that is feasible (or more likely, feasible in an acceptable time frame) is another question 😄

As for the fsgroup strategy, do you mean https://kubernetes.io/docs/concepts/policy/pod-security-policy/#fsgroup or some generic methodology within Kubernetes?

Yes

I have now filed kubernetes/kubernetes#55707 as an alternative approach where I make the remapped uid/gid an explicit option, and use those values to chown/chgrp the necessary directories.

👍 subscribed

@adelton
Copy link

adelton commented Nov 14, 2017

When you say transparent, you mean that nothing should be needed to be added to code or to configuration on Kubernetes' side to allow running under docker with userns-remap?

that would be ideal. Whether that is feasible (or more likely, feasible in an acceptable time frame) is another question

Ideally, the pod would specify how many distinct uids/gids it would require / list of uids it wants to see inside of the containers, and docker or different container runtime would setup the user namespace accordingly. But unless docker also changes ownership of the volumes mounted to the containers, Kubernetes will have to do that as part of the setup.

@adelton
Copy link

adelton commented Dec 7, 2017

@pwel-, what is the best way to get some review and comments on kubernetes/kubernetes#55707, to get it closer to mergeable state?

@0xmichalis
Copy link

0xmichalis commented Dec 7, 2017

@pweil- ^

@pweil-
Copy link
Member

pweil- commented Dec 7, 2017

@adelton I would try to engage the sig-node folks either at their Tuesday meeting or on slack: https://github.com/kubernetes/community/tree/master/sig-node

@adelton
Copy link

adelton commented Dec 18, 2017

@derekwaynecarr, could you please bring kubernetes/kubernetes#55707 to sig-node's radar?

@idvoretskyi
Copy link
Member

idvoretskyi commented Jan 22, 2018

@pweil- @derekwaynecarr any progress on this feature is expected?

@k8s-ci-robot k8s-ci-robot added this to the v1.25 milestone Jun 9, 2022
@Priyankasaggu11929 Priyankasaggu11929 added the tracked/yes Denotes an enhancement issue is actively being tracked by the Release Team label Jun 9, 2022
@parul5sahoo
Copy link
Member

parul5sahoo commented Jun 9, 2022

Hello @rata 👋, 1.25 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 16, 2022.

For note, This enhancement is targeting for stage alpha for 1.25 (correct me, if otherwise)

Here's where this enhancement currently stands: (updated on June 9, 2022)

  • KEP file using the latest template has been merged into the k/enhancements repo.
  • KEP status is marked as implementable
  • KEP has a updated detailed test plan section filled out
  • KEP has up to date graduation criteria
  • KEP has a production readiness review that has been completed and merged into k/enhancements.

KEP PR #3275 addressed all checkboxes!

For note, the status of this enhancement is marked as tracked. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

@rata
Copy link
Member

rata commented Jun 9, 2022

@parul5sahoo I think the place-holders weren't replaced in your message. So, to avoid confusions, let me tell you that:

  • We are targeting alpha stage for 1.25
  • It is correct that none of the check boxes are ticked now. But all should be ticked probably by today EOD. I'll update you when that is done

Thanks!

@rata
Copy link
Member

rata commented Jun 9, 2022

@parul5sahoo well, it happened faster. Now all the check boxes you mentioned are done :)

@parul5sahoo
Copy link
Member

parul5sahoo commented Jun 9, 2022

@rata apologies for the misunderstanding created because of that, it was the first time I did reach out to a KEP owner as an Enhancements shadow, thank you for understanding and verifying it.

@rata
Copy link
Member

rata commented Jun 9, 2022

@parul5sahoo no problem, I understood everything! And thanks again :)

@giuseppe
Copy link
Member

giuseppe commented Jun 13, 2022

opened a PR to add the CRI changes: kubernetes/kubernetes#110535

@sethmccombs
Copy link

sethmccombs commented Jul 12, 2022

Hello @rata! 👋,

1.25 Release Docs Shadow here.

Does this enhancement work planned for 1.25 require any new docs or modification to existing docs?

If so, please make sure to open a PR against the dev-1.25 branch in the k/website repo (follow the steps here)

This PR can be just a placeholder at this time and must be created before August 4.

Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release.
Thank you!

@rata
Copy link
Member

rata commented Jul 15, 2022

k/k PR is open for a few days now: kubernetes/kubernetes#111090

@Priyankasaggu11929
Copy link
Member

Priyankasaggu11929 commented Jul 21, 2022

Hi @rata 👋

Checking in once more as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022.

Please ensure the following items are completed:

Please verify, if there are any additional k/k PRs besides the ones listed above.

Please plan to get the open PRs merged by the code freeze deadline. The status of the enhancement is currently marked as at-risk.

Also kindly update the issue description with the relevant links for tracking purposes. Thank you so much!

@rata
Copy link
Member

rata commented Jul 22, 2022

@wojtek-t can you please update the PR description (or maybe I can join some team and do it myself? I'm part of the k8s org for several years) with this? Thanks!

k/k PRs:

docs PR:

enhancements PRs:

blog post PR:

@rata
Copy link
Member

rata commented Jul 28, 2022

@wojtek-t friendly ping?

@wojtek-t
Copy link
Member

wojtek-t commented Jul 28, 2022

I don't think we need to have them in the description - it's enough for them to be linked to this issue.

@Priyankasaggu11929
Copy link
Member

Priyankasaggu11929 commented Aug 1, 2022

Hello @rata 👋

Just a gentle reminder from the enhancement team as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022 (which is two days from now).

Please plan to have the open k/k PR merged before then.

The status of this enhancement is currently marked as at risk. Thank you.

@Priyankasaggu11929
Copy link
Member

Priyankasaggu11929 commented Aug 3, 2022

Hello 👋, 1.25 Enhancements Lead here.

Unfortunately, this enhancement did not meet the code freeze criteria because there are still unmerged k/k code PRs.

The RT leads are evaluating the exception request & will get back! Thank you!

/milestone clear

@k8s-ci-robot k8s-ci-robot removed this from the v1.25 milestone Aug 3, 2022
@Priyankasaggu11929 Priyankasaggu11929 added this to the v1.25 milestone Aug 5, 2022
@rhockenbury rhockenbury added tracked/no Denotes an enhancement issue is NOT actively being tracked by the Release Team and removed tracked/yes Denotes an enhancement issue is actively being tracked by the Release Team labels Sep 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. sig/node Categorizes an issue or PR as relevant to SIG Node. stage/alpha Denotes an issue tracking an enhancement targeted for Alpha status tracked/no Denotes an enhancement issue is NOT actively being tracked by the Release Team
Projects
No open projects
Development

No branches or pull requests