Why Linux file permissions don't provide sufficient security?
Need to understand Kubernetes security? Start here.
When I was a young lad, I thought Linux security was all about choosing Boeing plane models. Then I grew up and discovered there was a whole world of complexity.
Let me explain. Donât worry, youâll understand the Boeing reference soon.
Traditional Linux file Permissions
Files on Linux have always had two important security properties:
File owner - e.g. natan
File permissions - e.g. natan is allowed to read and write, other users are allowed to read
Instead of representing file permissions as a human-readable sentence (the file owner can read and write), permissions are traditionally represented as a 3-digit number, containing the digits 0-7.
For reasons, I wonât go into, the most common file permissions are all numbers of Boeing plane models: 747, 777, etc.
Funny naming conventions aside, every Linux file has an owner and a set of permissions saying which users can read, write, and execute it.
Whatâs missing from file permissions?
The above security model is awesome. Itâs not as sophisticated as the security model that Microsoft Windows uses1, but it's way simpler.
However, the traditional Linux model breaks down when it comes to non-file security.
For example, how can you implement common restrictions like:
Processes shouldnât be visible to other processes running on the system, unless they are related.
Wireshark is allowed to sniff network packets, but other programs are not allowed.
JavaSpringBootFactoryCreatorSoapAPI.jar should not be allowed to hog all the CPU and memory.
The answer isnât file permissions. Clearly, Linux needs additional security and isolation features beyond files.
What does Kubernetes require from Linux?
What does any of this have to do with Kubernetes? This is a Kubernetes newsletter, after all!
Well, you canât build a skyscraper from mud bricks, and you canât build a secure Kubernetes cluster from only Linux file permissions.
Here are some of Kubernetes security and isolation requirements from Linux:
Pods should be isolated from one another. E.g:
Processes inside one pod shouldnât be able to see processes from another pod.
Each pod should have its own âminiature networkâ for just that pod.
Pods shouldnât be able to modify the node itself, unless given explicit permission. E.g:
A pod shouldnât be able to reboot the node.
Pods shouldnât be able to hog the node. E.g:
Pods should have CPU requests and Limits. (Even though, those damn Kubernetes CPU limits arenât necessary.)
These arenât the full requirements, but you get the idea.
How does Kubernetes security actually work?
In the next issues of this Substack, weâll dive into various Kubernetes features and what Linux security features enable them under the hood.
As always, you can subscribe to avoid missing newsletter issues.
Iâd love to do a future post on MACs, DACs, and ACLs, even though itâs way out of scope for a Kubernetes newsletter.