Applying KubeArmor pod annotations

[nyrahul]

Feature Request

Short Description

Currently, KubeArmor watches for deployments and uses the rolling update feature to apply the required annotations. There are following annotations that are of interest.

Annotations:  container.apparmor.security.beta.kubernetes.io/ubuntu-1-container: localhost/kubearmor-multiubuntu-ubuntu-1-container
              kubearmor-policy: enabled
              kubearmor-visibility: process,file,network

• the first annotation enables AppArmor in the context of the pod
• the second annotation enables kubearmor based policy "enforcement" on the pod. Another option is to use "audited" here to only get the audit events for the pod.
• the third annotation enables visibility in the context of the pod for process, file, and network.

Is your feature request related to a problem? Please describe the use case.

Currently, KubeArmor does not have a way to apply annotations in the context of individual pods i.e, pods created without deployments.

Thus if the user applies a policy, the policy apply works but the actual enforcement does not. There is no way for the user to debug this.

Describe the solution you'd like

• we could rid kubearmor of all the annotations-related code and just use an admission controller to apply the annotation using mutatingwebhook.
• This would work for all types of pods (including created directly or created through deployments)

However, this approach needs proper analysis of the dependencies.

Describe alternatives you've considered

• Just do documentation update: We do not expect pods to be created without deployments in the real world. However, this assumption may be wrong.
• Use the Kubearmor client tool to show the status. In the status, we can show the pods without deployment and highlight the risk.

CC: @nam-jaehyun

[nthnieljson]

@nyrahul Hello, I am interested in this project and want to take this as my LFX mentorship project (referring to https://mentorship.lfx.linuxfoundation.org/project/81f0d863-30ca-43b5-a368-fd422ec681a6). I have already applied to the LFX mentorship website and also submitted my prerequisite tasks. Thank you!

[nyrahul]

@nyrahul Hello, I am interested in this project and want to take this as my LFX mentorship project (referring to https://mentorship.lfx.linuxfoundation.org/project/81f0d863-30ca-43b5-a368-fd422ec681a6). I have already applied to the LFX mentorship website and also submitted my prerequisite tasks. Thank you!

Great to see your interest in solving this problem. We would be happy discuss the problem statement and possible design choices we had considered.

[achrefbensaad]

@nyrahul , we cannot use mutation webhooks to annotate pods because when mutating we dont know on what node the pod will end up running on. in other words we cannot set the correct annotations for a perticular enforcer in the case that we have multiple types of enforcers in a cluster.
I would suggest that we use a controller that will watch for pods and annotate them, relatevly the same logic of watchK8SPods go routine except that we will be using patches rather than re-creating a new pods, by patching we will not invoke a deployment, replicaset, "other PodGenerators" re-consiliation as pod membership is determined by labels rather than annotations. and in order to determine the enforcer type with minimal effort, i suggest that we add a logic to the NewRuntimeEnforcer function to annotate the node with the value of EnforcerType attribute during initialization.

[nyrahul]

Thanks @achrefbensaad for handling this issue. Closing this since this is now tested as well.