0

I'm struggling with specifying correct parameter value for Azure policy named "Overriding or disabling of containers AppArmor profile should be restricted" - allowedProfiles parameter.

From k8s docs, I can use kubectl exec <POD_NAME> --namespace="<NAMESPACE>" -- cat /proc/1/attr/current to get to know what profiles are enabled. When running it against few pods, I can see mostly there is following profile enabled:

cri-containerd.apparmor.d

However, when I try to put that into policy parameter allowedProfiles (value was [ "cri-containerd.apparmor.d" ]) it does not make resource healthy. I was also trying with values in the parameter hint (i.e. [ "runtime/default", "docker/default"]), but the effect was the same: still unhealthy resource.

Robert Skarżycki
  • 363
  • 1
  • 9
  • Hello @RobertSkarzycki , as per the builtin-policy the allowed values can be empty if you want to block all or if you want you can mention the allowed values in a way which you are already using . – Ansuman Bal Dec 10 '21 at 06:19
  • but as per your ask , what I understand is that the AKS is an existing resource and then you are applying the policy which is remaining non-complaint even after you have mentioned the allowed values . if thats the case , may i know if you have tried tried creating a remediation task for the same policy ? you can refer this [Microsoft Document](https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources#:~:text=To%20create%20a%20remediation%20task,%20follow%20these%20steps:,tab%20and%20data%20table.%20...%20More%20items...%20) on how to do the same . – Ansuman Bal Dec 10 '21 at 06:25
  • @AnsumanBal-MT, does it mean changes to the policy assignment (setting the parameter value) is not applied to the existing resource? That would be strange, as other policies rather check existing resources... – Robert Skarżycki Dec 22 '21 at 09:54
  • yes, other polices also need remediation for existing resources – Ansuman Bal Dec 22 '21 at 12:34

1 Answers1

0

Firstly, provide the allowed profile name(s) as an input for the constraint (policy). You can use the "runtime/default" if you want to use whatever is provided with AKS. Alternatively create your own AppArmor profile and pass it as allowed.

Secondly, in your YAML definitions (for Pods, Deployments, Jobs etc.) you need to make sure you are actualy using the AppArmor profile, i.e. for Pods:

...
annotations:
  container.apparmor.security.beta.kubernetes.io/pod-allowed: runtime/default
  container.apparmor.security.beta.kubernetes.io/pod-allowed-sidecar: runtime/default
...
dmusial
  • 1,504
  • 15
  • 14
  • Hm... @dmusial, but what if I don't want to explicitly use any of profiles? Am I forced to set `runtime/default`? And what is a profile `cri-containerd.apparmor.d` that I can find as apparently enabled, but it is not set in my YAMLs? – Robert Skarżycki Dec 22 '21 at 09:51
  • I am not aware of any mechanism in k8s which would allow you to specify a default AppArmor profile for all objects implicitly. In order to apply an AppArmor profile you have to amend your existing YAMLs. As for cri-containerd.apparmor.d, this is a default containerd AppArmor profile, it will get used if you specify the 'runtime/default' in your YAMLs. – dmusial Dec 23 '21 at 10:54