Provide RunAsGroup feature for Containers in a Pod

[krmayankk]

Feature Description

As a Kubernetes User, i should be able to specify both user id and group id for the containers running inside a pod on a per Container basis, similar to how docker allows that using docker run options -u, --user="" Username or UID (format: <name|uid>[:<group|gid>]) format. Currently kubernetes only allows us to control the primary user id and allows us to add supplemental groups. There is no way to control the primary group id of the running container which is always 0(root).
This feature would enable enterprises to run containers as non root(non zero uid and non zero gid) and hence improve the level of security for the running containers. More discussion and agreement was gathered in this issue 22179

• One-line feature description (can be used as a release note): Provide RunAsGroup feature for Containers in a Pod
• Primary contact (assignee): @krmayankk
• Responsible SIGs: sig-node, sig-auth
• Design proposal link (community repo): Allow specifying the primary group id of the container community#756
• KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190131-runas-groupid.md
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @pmorie @liggitt @tallclair
• Approver (likely from SIG/area to which feature belongs): TBD
• Feature target (which target equals to which milestone):
  Alpha release: v1.10
  Beta release: v1.14
  Stable release target v1.15

List of Work Items:-

• RunAsGroup Implementation
• Add feature flag , mark it alpha and disable by default
• PSP Implementation for RunAsGroup
• Verify e2e and Unit test Coverage
• Verify Containerd and cri-o Test coverage

Containerd and Cri-o Implementation PR's

• container_create: support CRI RunAsGroup cri-o/cri-o#1601
• RunAsGroup fixes and tests cri-o/cri-o#1898
• Add RunAsGroup support. containerd/cri#710

Test Results for CRI-O PR with latest Kubernetes Master
https://k8s-testgrid.appspot.com/sig-node-cri-o#crio-e2e-fedora

Test Coverage for CRI-O and containerd tests running as part of critest

• https://github.com/kubernetes-sigs/cri-tools/blob/16911795a3c33833fa0ec83dac1ade3172f6989e/pkg/validate/security_context_linux.go#L357
• https://github.com/kubernetes-sigs/cri-tools/actions?query=workflow%3A%22critest+containerd%22
• https://github.com/kubernetes-sigs/cri-tools/actions?query=workflow%3A%22critest+CRI-O%22

Is the progress listed above accurate?

[krmayankk]

I started working on this earlier but got distracted by other higher priority issues . We need this feature hence I will prioritize this again . Expect a PRoposal and a first PR in the next couple weeks

On Tue, May 2, 2017 at 8:46 AM Dennis Schridde ***@***.***> wrote: Is the progress listed above accurate? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#213 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AP4-NM7iZmBnKFNe_ywx_6BSd_Aecz_Vks5r10_BgaJpZM4MhoLz> .

-- -Mayank

[pineking]

@krmayankk any progress to update?

[krmayankk]

@pineking i have the proposal , and the code almost ready. Will send out the proposal by Friday while i try to figure the unit tests and api changes.

[jduncan-rva]

@krmayankk is this still on your radar?

[krmayankk]

@jduncan-rva yes the proposal is already out. I have some review comments which i will address. I should have a PR by next week.

[kincl]

@krmayankk any updates?

[krmayankk]

@kincl the proposal is already out and nearing lgtm. We are waiting one more reviewer to review. I was out last week on vacation. I should have the actual PR this week

[krmayankk]

Here is the proposal under review kubernetes/community#756

[php-coder]

Responsible SIGs: sig-node

Sounds like it falls into sig-auth area.

[php-coder]

For the history: here is an implementation of the proposal -- kubernetes/kubernetes#52077

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale