I'm not sure it's fair to say the advantages of selinux are solely around sharing services and filesystems on a host. I believe selinux also allows a more expre

I'm not sure it's fair to say the advantages of selinux are solely around sharing services and filesystems on a host. I believe selinux also allows a more expressive policy on how a running piece of software can interact with the kernel than say seccomp can, which is probably what you're container runtime is using to limit kernel access. And unless you're configuring seccomp, you're probably picking up some default policy designed to work on as many systems as possible, which sort of violated least privilege. I'm also not sure I would consider this a totally solved problem within kubernetes. In supporting gravity, our kubernetes distribution, we used to hard-disable all privileged containers. This become a common point of friction, since many pieces of common kubernetes software seemed to just use privileged containers instead of properly listing and setting needed capabilities. Although this is a separate issue from selinux, I'm just pointing out that many kubernetes clusters may not be as isolated between running processes as expected. And to answer what the product is, gravity is a kubernetes distribution, that in this use case allows for packaging a kubernetes based application together with the runtime, for a unified installer for the application + runtime. Think something like packaging up a SAAS application, and being able to install a copy within a banks network who doesn't want their systems talking to the internet while abstracting away the kubernetes portions. The problem we were running into, is that end user would keep trying to install the application onto selinux enabled hosts, which would break the install or runtime. And whether you believe in selinux or not, it causes significant friction to try and tell your customers we got this, just turn off that security feature in production.