-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
Kubelet: Add security context for Windows containers #64009
Kubelet: Add security context for Windows containers #64009
Conversation
@feiskyer: GitHub didn't allow me to request PR reviews from the following users: taylorb-microsoft, PatrickLang. Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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. |
/retest |
i am asking @bsteciuk to review this as well. at a high level it looks good to me but i don't know enough to do a good code review here |
/sig windows /retest |
/retest ping @dchen1107 @bsteciuk |
// setup security context | ||
effectiveSc := securitycontext.DetermineEffectiveSecurityContext(pod, container) | ||
// RunAsUser only supports int64 from Kubernetes API, but Windows containers only support username. | ||
// TODO: change RunAsUser to intstr in Kubernetes API. |
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.
Do we need to change it? I'm wondering whether its better to use one field as IntStr that requires different types for Windows vs Linux, or if we should just have two different fields - Int for Linux, Str for Windows?
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.
My preference is to keep the fields separate but open to feedback
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.
From CRI perspective, it supports both int64 and string for Linux containers but only string for Windows containers. While in today's API, only int64 is supported yet. So changing kubernetes API to IntStr will work for both Linux and Windows.
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.
Ah, I see. So converging DetermineEffectiveSecurityContext will require the API change later. This PR just adds the new field run_as_user which is Windows only.
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.
exactly
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 think username could also be verified, e.g. administrator on Windows or root on Linux.
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.
If the docker images will run as user "foo" by default inside the container, (today) kubelet can't check what uid "foo" maps to, and whether it's actually root on the host.
How does this work for windows?...
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.
Privileged mode isn't implemented on Windows, and the container administrator account is separate because the filesystem and registry (where the user profile is) are separate from the host's. Putting a check on username won't add any security.
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.
If you do want it for consistency with Linux, it could be done but would need to check against localized variants of "Administrator" since microsoft/windowsservercore is localized
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.
If the docker images will run as user "foo" by default inside the container, (today) kubelet can't check what uid "foo" maps to, and whether it's actually root on the host.
@yujuhong Good catch. Even non-root username could have uid 0 on Linux, so username won't make sense for linux security context.
If you do want it for consistency with Linux, it could be done but would need to check against localized variants of "Administrator" since microsoft/windowsservercore is localized
@PatrickLang I think checking localized variants not possible because kubelet won't handle container localization.
Let me remove the todo item.
/milestone v1.11 |
/kind api-change |
/lgtm |
This PR does not look critical for 1.11, and is not in an ready-to-merge state. As such, it will be removed from the 1.11 milestone by the milestone bot when Code Freeze starts at midnight UTC / 5pm PDT. If you feel it is critical to 1.11, please upgrade its priority to critical-urgent |
@tallclair or @derekwaynecarr any updates? There were some questions about usernames but no changes requested. |
Filed #64801 to investigate PodSecurityPolicy later per @tallclair 's feedback |
/lgtm |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: feiskyer, PatrickLang, tallclair, yujuhong 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 |
Yep, we should add windows tests definitely. But the test infra is still not ready yet. We expect it ready next release. |
[MILESTONENOTIFIER] Milestone Pull Request: Up-to-date for process @PatrickLang @derekwaynecarr @feiskyer @tallclair @yujuhong Pull Request Labels
|
/test all [submit-queue is verifying that this PR is safe to merge] |
/test pull-kubernetes-integration |
Automatic merge from submit-queue (batch tested with PRs 64009, 64780, 64354, 64727, 63650). If you want to cherry-pick this change to another branch, please follow the instructions here. |
@feiskyer: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
What this PR does / why we need it:
This PR adds windows containers to Kubelet CRI and also implements security context setting for docker containers.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
RunAsUser from Kubernetes API only accept int64 today, which is not supported on Windows. It should be changed to intstr for working with both Windows and Linux containers in a separate PR.
Release note:
/cc @PatrickLang @taylorb-microsoft @michmike @JiangtianLi @yujuhong @dchen1107