search

kubearmor / KubeArmor

Runtime Security Enforcement System. Workload hardening/sandboxing and implementing least-permissive policies made easy leveraging LSMs (BPF-LSM, AppArmor).
https://kubearmor.io/
Apache License 2.0
1.31k stars 322 forks source link

Enhancement: Support new pod API for AppArmor profiles with Kubernetes 1.30+ #1673

Open DelusionalOptimist opened 3 months ago

DelusionalOptimist commented 3 months ago

Feature Request

Description KubeArmor supports using AppArmor as an enforcer for protecting Kubernetes pods and nodes. For pods/pod templates, this is done by adding the annotation container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref> till now.

However, AppArmor support is moving to GA 🥳 in the upcoming Kubernetes v1.30 release and the annotation would be soon removed in accordance to K8s' deprecation policy.

Describe the solution you'd like Once K8s 1.30 is released, support both the new AppArmorProfile field that's being added at pod and container level securityContext, along with the old annotation based mechanism for backward compatibility.

References

yp969803 commented 1 month ago

/assign

DelusionalOptimist commented 1 month ago

Thanks for showing interest @yp969803, do share how you plan to go about and feel free to ask any questions. : )

yp969803 commented 4 weeks ago 
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
   - name: example-container
    image: nginx
    securityContext:
      appArmorProfile: "localhost/example-apparmor-profile"
yp969803 commented 4 weeks ago

@DelusionalOptimist so, i have to make the controller to be compaitable with this type of yaml files also?

yp969803 commented 3 weeks ago

We can set the securityContext of the pod the time of pod mutation, will this works @DelusionalOptimist

DelusionalOptimist commented 3 weeks ago

Yes @yp969803 modifying the pod mutation logic in controller would be one of the parts. Just that we need to do it in a backwards compatible manner. Also note KubeArmor patches the pod's owner object (deployment, daemonset etc) as well right now as a fallback mechanism because it's possible that controller is not present in certain deployments - ref. So we need to handle that as well.

You can start by creating a PR for controller first then handle KubeArmor in a separate one. After the above two, you can handle operator related changes for detecting the Kubernetes version and accordingly setting which mechanism (annotation/securityContext) will be used (for backwards compatibility).

Feel free to ping here or on #kubearmor-project channel in KubeArmor slack. : )