Open DelusionalOptimist opened 8 months ago
/assign
Thanks for showing interest @yp969803, do share how you plan to go about and feel free to ask any questions. : )
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: nginx
securityContext:
appArmorProfile: "localhost/example-apparmor-profile"
@DelusionalOptimist so, i have to make the controller to be compaitable with this type of yaml files also?
We can set the securityContext of the pod the time of pod mutation, will this works @DelusionalOptimist
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. : )
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 levelsecurityContext
, along with the old annotation based mechanism for backward compatibility.References