adding feature for apparmor annotation

[jonathanmhurley]

RELNOTE: Adds a test for configuring an apparmor profile annotation in a Deployment with thresholds:
- exists (score 1 if missing)
- default (score 7 if configured as docker-default)
- ok (score 10 if configured and non-default)

link

AppArmor is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is configured through profiles tuned to whitelist the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either enforcing mode, which blocks access to disallowed resources, or complain mode, which only reports violations.

[zegl]

Requiring a AppArmor annotation can be a bit problematic,

1. AppArmor is a Linux feature. Kubernetes can also run on Windows these days, so requiring Windows-workloads to have a AppArmor annotation doesn't make sense to me.
2. There is a Kubernetes-native way to enforce AppArmor annotations via a PodSecurityPolicy.
3. The AppArmor API (in Kubernetes) is in beta, and has not been stabilized since it was released 10 minor versions ago.
4. AppArmor is not supported by all container runtimes, Kubernetes only supports AppArmor together with the docker and remote runtimes (ref).

This said, I'm for merging this features as a optional check that can be enabled with the --enable-optional-test flag. But then I guess that this check should support even more APIs than just Deployment, I think that all of StatefulSet, Pod, DaemonSet, Job, and CronJob deserve the same treatment.

[jonathanmhurley]

Hi Gustav,
That makes sense; I had presumed those not using it would skip but going the optional route should have the same effect. I'll put together some changes and update this PR.
Thanks.

FWIW I think this check is beneficial even considering your very valid point about PSP because PSP must be enabled at the cluster level and fails closed so apparmor is a good vehicle to get some of the security if there's a blocking reason why a cluster can't be changed.

[filintod]

I think it will be good to check if the annotation is set to "unconfined" as that will be skipping apparmor
.