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

Support User Namespaces in pods #127

Open
18 of 22 tasks
derekwaynecarr opened this issue Oct 10, 2016 · 216 comments
Open
18 of 22 tasks

Support User Namespaces in pods #127

derekwaynecarr opened this issue Oct 10, 2016 · 216 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. lead-opted-in Denotes that an issue has been opted in to a release sig/node Categorizes an issue or PR as relevant to SIG Node. stage/beta Denotes an issue tracking an enhancement targeted for Beta status
Milestone

Comments

@derekwaynecarr
Copy link
Member

derekwaynecarr commented Oct 10, 2016

Enhancement Description

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

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

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

@pweil-
Copy link

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

@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

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

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

@pweil- ^

@pweil-
Copy link

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

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

@salehsedghpour
Copy link
Contributor

/remove-label lead-opted-in

@k8s-ci-robot k8s-ci-robot removed the lead-opted-in Denotes that an issue has been opted in to a release label Jan 6, 2024
@salehsedghpour
Copy link
Contributor

Hello 👋 1.30 Enhancements Lead here,

I'm closing milestone 1.29 now,
If you wish to progress this enhancement in v1.30, please follow the instructions here to opt in the enhancement and make sure the lead-opted-in label is set so it can get added to the tracking board and finally add /milestone v1.30. Thanks!

/milestone clear

@k8s-ci-robot k8s-ci-robot removed this from the v1.29 milestone Jan 16, 2024
@rata
Copy link
Member

rata commented Jan 17, 2024

As we discussed in sig-node, we want to make changes in 1.30 too. Can we add it to the milestone? cc @SergeyKanzhelev @mrunalp

@thockin
Copy link
Member

thockin commented Jan 24, 2024

Is this moving to beta in 1.30 or just evolving some?

@giuseppe
Copy link
Member

we would like to. We are currently working on an update for the KEP and propose to move the feature to beta in 1.30

@thockin
Copy link
Member

thockin commented Jan 24, 2024

PRR Freeze is imminent, leaving KEP updates to the last week adds a lot of risk to being able to make progress. Please ping when updates are ready :)

@giuseppe
Copy link
Member

PRR Freeze is imminent, leaving KEP updates to the last week adds a lot of risk to being able to make progress. Please ping when updates are ready :)

just opened a PR: #4439

@SergeyKanzhelev
Copy link
Member

/stage beta
/milestone v1.30

@k8s-ci-robot k8s-ci-robot removed the stage/alpha Denotes an issue tracking an enhancement targeted for Alpha status label Jan 26, 2024
@k8s-ci-robot k8s-ci-robot added this to the v1.30 milestone Jan 26, 2024
@k8s-ci-robot k8s-ci-robot added the stage/beta Denotes an issue tracking an enhancement targeted for Beta status label Jan 26, 2024
@salehsedghpour
Copy link
Contributor

Hello @mrunalp, @derekwaynecarr and @vikaschoudhary16 , 1.30 Enhancements team here! Is this enhancement targeting 1.30? If it is, can you follow the instructions here to opt in the enhancement and make sure the lead-opted-in label is set so it can get added to the tracking board? Thanks!

@rata
Copy link
Member

rata commented Jan 29, 2024

@salehsedghpour yes, it is targeting 1.30. What step from there is missing?

@salehsedghpour
Copy link
Contributor

@rata, lead-opted-in label is missing.

@rata
Copy link
Member

rata commented Jan 29, 2024

@salehsedghpour ohh, I missed that 🙈 ! @SergeyKanzhelev @mrunalp can you please add the lead-opted-in label?

@mrunalp
Copy link
Contributor

mrunalp commented Feb 7, 2024

/label lead-opted-in

@k8s-ci-robot k8s-ci-robot added the lead-opted-in Denotes that an issue has been opted in to a release label Feb 7, 2024
@tjons
Copy link

tjons commented Feb 8, 2024

Hello @giuseppe 👋, Enhancements team here.

Just checking in as we approach enhancements freeze on Friday, February 9th, 2024 at 02:00 UTC.

This enhancement is targeting for stage beta for 1.30 (correct me, if otherwise)

Here’s where this enhancement currently stands:

  • KEP readme using the latest template has been merged into the k/enhancements repo.
  • KEP status is marked as implementable for latest-milestone: 1.30. KEPs targeting stable will need to be marked as implemented after code PRs are merged and the feature gates are removed.
  • KEP readme has up-to-date graduation criteria.
  • KEP has submitted a production readiness review request for approval and has a reviewer assigned.
  • KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here).

With all the KEP requirements in place and merged into k/enhancements, this enhancement is all good for the upcoming enhancements freeze. 🚀

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

@tjons
Copy link

tjons commented Feb 9, 2024

With all the requirements fulfilled this enhancement is now marked as tracked for the upcoming enhancements freeze 🚀

@Checksumz
Copy link

Hi @derekwaynecarr ,

👋 from the v1.30 Communications Team! We'd love for you to opt in to write a feature blog about your enhancement!

We encourage blogs for features including, but not limited to: breaking changes, features and changes important to our users, and features that have been in progress for a long time and are graduating.

To opt in, you need to open a Feature Blog placeholder PR against the website repository.
The placeholder PR deadline is 27th February, 2024.
Here's the 1.30 Release Calendar

@sftim
Copy link
Contributor

sftim commented Feb 15, 2024

Blog team editor here: please do consider opting in. Say hi in Slack (#sig-docs-blog) if you have any questions. This is beta a big thing to announce.

@drewhagen
Copy link
Member

drewhagen commented Feb 15, 2024

Hello @derekwaynecarr 👋, 1.30 Docs Lead here.

Does this enhancement work planned for 1.30 require any new docs or modification to existing docs?
If so, please follows the steps here to open a PR against dev-1.30 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday February 22nd 2024 18:00 PDT.

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 Feb 16, 2024

@Checksumz thanks! I'm interested in writing a blog post for the 1.30 release. Let me confirm during next week if I'll do it. I want to check some stuff with other project releases.

@drewhagen yes, there are doc changes on this release. I've just opened a placeholder PR: kubernetes/website#45178. Thanks for the remainder!

@Checksumz
Copy link

@Checksumz thanks! I'm interested in writing a blog post for the 1.30 release. Let me confirm during next week if I'll do it. I want to check some stuff with other project releases.

@drewhagen yes, there are doc changes on this release. I've just opened a placeholder PR: kubernetes/website#45178. Thanks for the remainder!

thanks for your response @rata

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. lead-opted-in Denotes that an issue has been opted in to a release sig/node Categorizes an issue or PR as relevant to SIG Node. stage/beta Denotes an issue tracking an enhancement targeted for Beta status
Projects
Status: Tracked
Status: Tracked
Status: Tracked for Code Freeze
Status: Tracked for Enhancements Freeze
Development

No branches or pull requests