ingore apparmor on windows #93220
ingore apparmor on windows #93220
Conversation
|
/sig node |
|
/sig windows |
|
@wawa0210: The label(s) 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 |
There was a problem hiding this comment.
Thanks for taking a look at this issue @wawa0210 !
To start, could we talk through some of the diff options for solving this issue?
One option, which you've already implemented, definitely seems to be gating the appArmorValidator on the runtime, and not starting if its windows. However, I'm curious about how this will work on non-Windows/non-Linux operating systems (i.e. FreeBSD and Darwin), which I imagine also doesn't support app armor.
However, I think there may be other options as well - off the top of my head, I think there are at least three.
-
Do some kind of runtime check around whether the system running the
kubeletsupports app armor, and only add the admit handler if it does. -
Make it so that, if the app armor validator is attempting to run on a non-supported platform, the validator itself is smart enough to fail gracefully.
-
As you mentioned, break out this runtime specific component into a separate file using build tags.
We may find that, after exploring all options, the initially proposed one is the best. Still, I think it would be useful to think through the pros and cons of this option :)
|
Thank you so much for such a detailed comment Before I start, I also thought about different ways to implement it, as you said
I don't recommend using this method,it will judge it like an armor validator at the specific logic level, and then to fail gracefully. But in the future, there will be many features like this, so that the same judgment will be written and executed
I also want to implement it in this way, but it seems that the current logic is only here. Therefore, I tried to use the first relatively simple way. If there are such features later, maybe it is a better choice to split and refactor. |
98b0dd9 to
8dc5528
Compare
|
/retest |
|
/milestone v1.20 |
|
/test pull-kubernetes-e2e-kind-ipv6 |
|
It feels odd to me that this behavior differs from the behavior we get when trying to run a pod on a linux node without apparmor. What do users do today when they have clusters with some nodes that do/don't support AppArmor? Or do we currently assume AppArmor is either enabled or disabled on all nodes? What makes windows special in this regard? I have the same discomfort with this as I had with #92355 (comment). The current behavior is that if you ask for AppArmor on your pod, and the node cannot satisfy it, we don't run your pod. That seems like the most secure behavior, so a misconfigured node or being scheduled to a node you didn't intend doesn't silently result in a security incident. A warning when creating the object is better, but it sounds like multi-arch images mean we can't do validation at that point. Why isn't the right answer here: "Don't apply an AppArmor SP to your pod if you want to run without AppArmor"? |
specifically for AppArmor, it would never be enabled on Windows as it is a Linux kernel component. I don't think there is a misconfigured node scenario in the case where
Important question. It might not be the ccorrect answer but from the other discussions there was a an expectation from windows users that since it is not valid for Windows it wouldn't come into play. For comparison, I ran a pod with SecurityContext.WindowsOptions and SecurityContext.seLinuxOptions set on a linux node (which didn't have seLinux enabled) and it was scheduled. Maybe there needs to be another look at this more holistically? |
|
thinking on it some more, the multi-arch use case might be the scenario that was the impetus for #93475. @ravisantoshgudimetla could you share more info on your expectations? |
|
This discussion reminds me of #75215
|
|
/lgtm |
|
/cc |
To me, ignoring the linux specific security constructs on kubelet side makes sense for now. There are distributions of Kube like OpenShift that apply SELinux options to the pods at the admission and this was the reason for starting #93475. I think, the fundamental problem is we want to distinguish Linux from Windows pods at the scheduling time using nodeSelector and tolerations but we have some api within the pod Spec that can be defaulted at the admission time. Unless we enforce runtime class and have reserved label which says |
|
Looking forward to your comments, thanks |
sorry, didn't realize this was pending my comments... what section specifically? |
sig-windows agrees that this pr can solve the current scenario where apparmor is not applicable to windows~ but @dashpole seems to have some different suggestions.Do you have any suggestions? |
That seems like a reasonable position for non-apparmor linux nodes which could happily unsafely run a linux container you would have thought would be protected by apparmor. If the container is a multi-arch container that supports windows, I don't think there will be confusion that the windows container runs without apparmor If we were structuring the pod spec today, we'd likely group things like apparmor, selinux, and seccomp options in a |
|
I guess it's just me then. I don't have any powers here anymore, though. |
|
/assign @sjenning |
|
/assign @sjenning @derekwaynecarr easy PR, already approved by @dashpole :) |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dashpole, dims, michmike, sjenning, wawa0210 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 |
|
/retest |
What type of PR is this?
/kind bug
What this PR does / why we need it:
AppArmor is a Linux kernel security module.and It does not support windows
At present, the startup logic of kubelet does not deal with this logic, which causes apparmor to be running on windows, causing an exception
Which issue(s) this PR fixes:
Fixes #93165
Special notes for your reviewer:
AppArmor is a linux kernel security module and it does not support other operating systems.
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/sig windows