Why do we use SELinux Policies as it overlaps other controls such as Linux Namespaces, K8S/Container security?

Question

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?

Examples are:

1. 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?
2. 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?
3. 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?
4. 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.

Thank you

Answer 1

At a foundational level Linux container security as popularized by Docker, is a series of controls which sometimes overlap (namspaces, capabilities, cgroups, MAC(Apparmor/SELinux and Seccomp)

(IMHO) The reason for this is that there was no dedicated security sandbox in use and Docker had the task of creating something which provided reasonable protection without causing issues with running workloads (docker's goal was for contained applications to "just work")

In terms of AppArmor/SELinux typically those are not installed on the same server as different Linux distributions will use one or the other. Debian derived distributions use AppArmor, and Red Hat derived distributions use SELinux.

One of the benefits of overlapping control layers as we see in containerization is that if one layer fails another may catch the attack.

The downside of SELinux, and the reason it's often disabled or a stock policy used, is the perception that creating and managing SELinux policies is cumbersome and error prone.

Whether it's worth the effort of creating and managing custom SELinux policies is likely a risk management decision, there's no clear "yes|no" options. Where a company is doing something risky for example running a multi-tenant cluster, using SELinux is one option to harden workloads to reduce the risk of breakout.

It's possible to use other approaches to reach the same goal. For example using gVisor or Firecracker instead of standard Container isolation, could provide increased isolation with an easier implementation.

Alternatively if running managed Kubernetes in the cloud it may be easiest to use a "serverless" approach with kubernetes such as AWS Fargate.