Assigning `RuntimeDefault` AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor

[jfroy]

The operator assigns the special RuntimeDefault AppArmor profile on pods and containers when strict security is enabled. On any hosts where AppArmor is not enabled, the pod will be rejected by kubelet's AppArmor admission handler, with the error "Cannot enforce AppArmor: AppArmor is not enabled on the host". This needs to be made configurable, as not all clusters will have AppArmor enabled on all hosts.

[f41gh7]

Maybe, it's better to remove default AppArmor value. Main motivation for it adding it was default security rules for cloud providers. As far as I understand, azure provides preset of configured validation rules ( runAsRoot false and others). But reality is AppArmor and Selinux are not widely supported ( windows hosts don't have such option).

[suhasagasthya]

Same issue faced! AppArmor is blocking pods on hosts that dont have appArmor enabled, we dont use appArmor in our environments. +1 to remove the appArmor value from the default security context or pass it as an env to enable if needed only.

[f41gh7]

Issue must be fixed at v0.48.4 release