How We Built SELinux Support for Kubernetes
In this technical retrospective (2020), @twakefield shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 70 points
TOTAL DISCUSSIONS 32 comments
I've written a bunch of SELinux policy, also without being especially expert. The tooling is definitely getting better, but still there are many annoying things from the obscure file layout, the giant all-in-one everything-is-a-global policy[1], to the small annoyances like m4 in the policy files.
Of course you need to buy into the whole premise of SELinux - that in addition to simple Unix permissions you can use mandatory access control to fine-grain control everything that a process can do and get access to. Obviously this is a giant boil-the-ocean project that has consumed many good people for decades. For SVirt (secure virtualization) this was pretty successful, allowing many qemu instances to run on a single server, and confining them with SELinux so each can only access its own files even when they are all running as the same Unix user.
The linked article is a good intro.
[1] But they're fixing this, yay! I can't find a link now but there's a project to decentralise SELinux policy. Perhaps it's still an internal-only Red Hat project.
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.
While the article shows how they build SELinux policy from scrath, they also mention udica tool[1] which generates SELinux profile based on container inspection:
# podman inspect my_container_id | udica my_container
I wonder how much would the result be different in their case or how much time would they save by having the first version of the policy being generated this way instead of writing it from scratch.
[1] https://github.com/containers/udica ↗
An off-topic but somewhat related question. What is a good way to whitelist which applications can access the network on my desktop linux system? (Currently running Arch, but I distro-hop quite often). Years ago when I had a MacBook, I used a program called Little Snitch. I see that there is a similar application for Linux called OpenSnitch, but I’m hoping there is a better way to utilize the built in features of Linux rather than introducing a 3rd party kernel module. Are SELinux / AppArmor the answer? Cgroups? Something else?
SELinux was a good way of securing linux machines with many services sharing things like file systems and binaries.
k8s solves this in a different way. You can write applications that are completely stateless when spun up on a k8s node and can be limited to a read only file system. Your container can be a scratch container with no other executables binaries.
I don't know what their product is, but i seriously doubt mixing these two concepts is the right thing to do.