Hacker News Reader

Comment by lima | Hacker News Reader

What's the point of SELinux support in a k8s environment, where services are already sandboxed by the container runtime?

It's unsafe to run untrusted workloads in the host kernel using only namespaces - SELinux does not change this, no matter how much Red Hat wants it to be true. The kernel has a massive attack surface. For untrusted workloads, you need virtualization like gVisor or Kata/Firecracker which isolates workloads from the host kernel.

SELinux can mitigate some logic bugs in the container runtime, yes, but it doesn't make your containers secure.

Also, the title of this submission on HN is inaccurate - Gravitational did not build SELinux support for k8s. Red Hat did, a long time ago. They added support for SELinux to their own product, Gravity.

View on HN

SELinux would have prevented a number of container breakout issues.

That said, as someone one time worked on an SELinux issue in Docker and then became the defacto "expert"... it's a terrible mess, often coming with incompatible policy changes tied to kernel changes and policies which are stacked on top of each other like a house of cards that are difficult to tease apart for other distros.

Because MAC (ie. SELinux and AppArmor) is part of the tooling the container runtime needs to sandbox services. Without SELinux you end up with the awkward situation where services are running as real users on your system and there's no real way to confine them beyond that.

Defense in depth. Running untrusted code in a kubernetes cluster is risky even with the sandbox. SElinux adds another layer of protection

I would go further and say that SELinux (and AppArmor) aren't defense in depth but actually a necessary part of the tooling to implement sandboxing of containers.

The point is that containers are actually just running PIDS, if you were to escape the process, you would have access to the host without security measures like selinux. You can also use selinux stop things like interprocess communication.

Something I notice in regards to selinux, is many people don't understand that you are not just applying context to files, but also PID's. You can see the context of a PID by doing 'ps -eZ', similar to how you would with files. This allows you to create a finer degree of process seperation.

You are right though, RedHat has been doing this with OpenShift since 2011, and it is a major part of their security model. RedHat's current push is the deployment of rootless containers, which addresses similar concerncs.

My naive understanding is that containers do not provide complete security.

Also, I could see giving a user shell access within a container and still restricting what they do with SELinux.

OpenShift is the only Kubernetes distribution with SELinux in enforcing mode out of the box (that I know of) and this has stopped attacks in the past.

Reply on news.ycombinator.com