kubernetes: CRI: Behavior of empty AppArmor profile is not clearly defined.

For seccomp, we defined:

    // Seccomp profile for the sandbox, candidate values are:
    // * docker/default: the default profile for the docker container runtime
    // * unconfined: unconfined profile, ie, no seccomp sandboxing
    // * localhost/<full-path-to-profile>: the profile installed on the node.
    //   <full-path-to-profile> is the full path of the profile.
    // Default: "", which is identical with unconfined.

However for apparmor, we only defined:

    // AppArmor profile for the container, candidate values are:
    // * runtime/default: equivalent to not specifying a profile.
    // * localhost/<profile_name>: profile loaded on the node
    //    (localhost) by name. The possible profile names are detailed at
    //    http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference

From the definition, it seems that empty apparmor profile will be “unconfined”, because there is no other “unconfined” option.

However, it is not the case today. When apparmor profile is empty, we’ll return empty https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/dockershim/helpers.go#L203.

However, in docker, it will apply docker-default if apparmor profile is empty, when apparmor is enabled on the OS. https://github.com/moby/moby/blob/6b262572028cc249b7da8cc55459197395fdb33e/daemon/oci_linux.go#L788-L792

IIUC, this means that, as long as the node supports apparmor, docker-default will be applied to every pod, every container, no matter pod has apparmor label or not

Is this the behavior we want? @tallclair We should clearly define what is the expected behavior.

@feiskyer @yujuhong @mrunalp @mikebrow /cc @kubernetes/sig-node-api-reviews