Change:
return retErr } <ins> // ValidateHost verifies that the host and runtime is capable of enforcing AppArmor profiles. // Note, this is intentionally only check the host at kubelet startup and never re-evaluates the host // as the expectation is that the kubelet restart will be needed to enable or disable AppArmor support. </ins> func (v *validator) ValidateHost() error { return v.validateHostErr } <del> // Verify that the host and runtime is capable of enforcing AppArmor profiles. </del> <ins> // validateHost verifies that the host and runtime is capable of enforcing AppArmor profiles. </ins> func validateHost() error { // Check feature-gates if !utilfeature.DefaultFeatureGate.Enabled(features.AppArmor) {

Discussion:
This issue is created by this Currently AppArmor validator gets host info only . API . Would it make sense to do it dynamically every time ValidateHost is called? It would help to get the latest AppArmor status, which can be changed if AppArmor kernel module is loaded or unloaded.
/sig node
KEP xref:
/kind feature /triage accepted /sig security (adding sig security as well as they co-own a KEP)
seems like this is only one line change?
correct
/assign
How expensive is this check? The result of it is that we will stop admitting pods when it was disabled? Do we need to do anything about already running Pods? Ideally we want to update files in this PR to describe this behavior: (cc do you see any issues with this change?
- it's just doing a stat+read on (), then checking the first byte read, so overall it's pretty snappy. Probably not a super cache-friendly use case; if your node has apparmor config enabled, presumably you'd want that to kick in now_, rather than sometime soon whilst another pod might sneak in before then.
what is it in terms of time? Any delay on pod admission, especially this unnecessary will not be ideal. I don't care that much about enable AppArmor scenario - one can restart kubelet after this, should not be a big deal. Disable AppArmor scenario is harder. If it was disabled, we may want to stop admitting. But I'm not sure how immediate this should be. Also if we covering this scenario, we may need to understand how already running Pods will behave if it's disabled. In both cases - disabled and kubelet is still running. And disabled and kubelet being restarted. Should we re-admit Pods?
For me, locally, it's ~1.3ms, but that's entirely going to depend on the host its running on. If we can't handle a couple of milliseconds at pod admission, we probably shouldn't do this change at all. If we're going to admit a pod with AppArmor config, whilst AppArmor is enabled for the kubelet, I'd imagine we'd want to uphold that guarantee we're giving by admitting said pod? I'd err on the side of it being immediate, assuming we're okay with the time spent validating the host.

If we decide we want to provide this relatively strong guarantee that any running pod is aligned with the host + kubelet's config, I'd argue in favour of re-admission.
I'm trying to think of other implications. Any dependency on pod startup flow is not ideal. I cannot tell how important it is to pick up the change without the kubelet restart. I'd defer for for this. Mechanics of the change are lgtm
Yes, I agree with Sergey. Requiring Kubelet to be restarted on module loading/unloading does not seem unreasonable to me. Are there any other instance of the Kubelet handling (or not handling, for that matter) dynamic kernel modules? 3ms is not much, but it's not nothing. I personally don't see much value in this change.
Thanks for the review! closing.