-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Improve the API description of PodSecurityContext.SupplementalGroups
to clarify its unfamiliar behavior
#113047
Improve the API description of PodSecurityContext.SupplementalGroups
to clarify its unfamiliar behavior
#113047
Conversation
PodSecurityContext.SupplementalGroups
to clarify its unfamiliar behavior
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/remove-sig api-machinery |
aa41353
to
a7b8c68
Compare
a7b8c68
to
97cfd4d
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
/assign @liggitt |
// any container. Please remember that the group membership defined in the | ||
// container image is kept. That means, if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this part of the CRI spec or is it container-runtime implementation dependent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liggitt Thanks for a great question. However, as far as I know, I think this part is also still ambiguous in the CRI spec(v0.25.3): LinuxContainerSecurityContext.supplemental_groups, LinuxSandboxSecurityContext.supplemental_groups
message LinuxContainerSecurityContext {
...
// List of groups applied to the first process run in the container, in
// addition to the container's primary GID.
repeated int64 supplemental_groups = 8;
...
}
message LinuxSandboxSecurityContext {
...
// List of groups applied to the first process run in the sandbox, in
// addition to the sandbox's primary GID.
repeated int64 supplemental_groups = 5;
...
}
At least, I confirmed containerd and cri-o implemented this behavior. here is reproduction code.
Then, would it be better to update the CRI spec too?? I believe https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cri-api is what we update. Is this correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then, would it be better to update the CRI spec too?? I believe https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cri-api is what we update. Is this correct?
I updated cri-api at a913eaa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this part of the CRI spec or is it container-runtime implementation dependent?
I will ask this at sig-node and come back again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this part of the CRI spec or is it container-runtime implementation dependent?
I will ask this at sig-node and come back again.
I think right now, it's technically implementation dependent, because there's no declaration in the cri spec nor a test in critest to validate it. It seems this PR is aiming to update it to be part of the CRI spec (would not hurt to add a follow-up to test this behavior in github.com/kubernetes-sigs/cri-tools)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@haircommander Thank you for your comment!
I would like to clarify the behavior in the spec because most popular cri (containerd and crio) does.
Then, I will open a PR to add critest in github.com/kubernetes-sigs/cri-tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened a PR in cri-tools repo that adds a test case to critest: kubernetes-sigs/cri-tools#1005
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also added an e2e test case in k/k to test the updated API description: 9e88694
0bb5973
to
f7b0788
Compare
rebased to resolve conflict. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
…luding cri-api) so that it explicitly describe group information defined in the container image will be kept. This also adds e2e test case of SupplementalGroups with pre-defined groups in the container image to make the behaivier clearer.
f7b0788
to
ac1d5fd
Compare
Squashed all the previous commits into ac1d5fd. |
This comment was marked as off-topic.
This comment was marked as off-topic.
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: everpeace, liggitt, mrunalp 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:
Approvers can indicate their approval by writing |
/triage accepted |
What type of PR is this?
/kind documentation
/sig node
What this PR does / why we need it:
As reported #112879, the API description of
PodSecurityContext.SupplementalGroups
is ambiguous regarding how group membership defined in the container image is handled for the first process in the containers.Assume a pod spec be like the below:
Then, the first process of the container can belong to
groups=1000(runAsGroup), 50000(defined in the image), 60000(supplementalGroups)
in popular CRI implementations (it was confirmed in containerd and cri-o). here is reproduction code.I think this behavior would be unfamiliar and confusing to most cluster administrators and users. Moreover, when a cluster enforces some security policy that protects the value of
supplementalGroups
field, the effect of its enforcement is limited, i.e. user can easily bypass the enforcement just by using a custom image. And, the behavior(unexpected group membership) will cause unexpected file access permission. It would be a security concern in some use cases when usinghostPath
volumes because uid/gid matters in accessing contents inhostPath
volumes.Thus, this PR improved the API description to clarify this unfamiliar current behavior and added a warning about unexpected group membership for many cluster administrators.
Note: as reported #112879, we once reported this behavior to hackerone.com(
#1688374
) by following Kubernetes Security and Disclosure Information. Kubernetes Security Response Committee responded that this behavior "works as intended."Which issue(s) this PR fixes:
#112879 (fixed partially)
Special notes for your reviewer:
This is my first step to resolve #112879 described in #112879 (comment). As a next step, I will write a KEP(kubernetes/enhancements#3619) introducing a new API to customize the behavior (how group membership will be handled in the first process in the container) as proposed in #112879.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: