While learning SELinux policies in the Container/Kubernetes environment, I realized that there are other layers of controls that overlap with SELinux.
In these cases, what additional value can I can obtain from using SELinux?
- SELinux applies labels to containers and objects on the host (host here means the underlying host running the containers) to ALLOW or DENY an action (e.g. read/write) between the two. However, Containers utilize Linux Namespacing where containers would see a different file system layout (assuming that this is the majority of the cases in Production) unless we mount local volumes specifically. If a container does not require to access objects in the host's filesystem, wouldn't this be futile?
- SELinux lacks controls over Network controls and Linux Capabilities. It is also tedious to maintain granular SELinux policies, hence we are recommended to use Udica as an extension. However, Kubernetes allows us to set security context to DROP & then ADD Linux capabilities which also includes the ability to restrict networking. In this case, does SELinux add value?
- An merit of AppArmour is that it is a MAC control over the filesystem running within the container and not the underlying host's filesystem. This can provide control over what can be done within the container itself. In this case, wouldn't you prefer AppArmour over SELinux?
- For allowing containers to bind and expose network ports, I believe we can leverage Kubernetes Network policies to prevent ingress/egress traffic which can go down to the level of the port numbers. In this case, how can SELinux add value?
Please note that I have no hate for SELinux here. I am merely curious and trying to find value out of this in the presence of other overlapping tools.