Kelly Shortridge writes about security strategy, DevOps and security, and tools like Deciduous for building security decision trees.
HN links it for her SecObs post and the Deciduous tool, and she responds to feedback there.
First of all, thank you for taking the time to write this out.
The feedback is very valuable.
I will do my best to address each comment.
Let me start by laying out our design constraints.
We knew we wanted a handful of simple features:
- minimal
- immutable
- and secure
and we approached them with the willingness to do whatever it took to achieve them, no matter how different it would be from any Linux distribution today.
The degree to which we want to obtain minimalism is what I like to call "ultra".
Not a single file should be on the image that isn't absolutely needed.
Furthermore, not a single process should be allowed to run that isn't required to obtain the goal of running Kubernetes.
So we started by creating an image with just enough to run the kubelet and the kubelet only.
Obviously, this isn't practical, but it was a place to start.
In implementing our immutability design constraint we decided to:
- make the root filesystem read-only
- have no package manager
- not allow any generic use of the OS (i.e. it would be only for the purposes of running Kubernetes)
When optimizing for one thing, you often degrade another.
In our case, if we optimize for minimalism, then immutability becomes degraded.
We need to address a way to manage and debug the node, and we need libraries/binaries to do so.
With no package manager, this means everything must be baked into the image, and thus we degrade immutability.
Tacking on yet another design constraint, security,…
SecObs (https://swagitda.com/blog/posts/the-security-obstructionism-secobs-market/) at it again!