Part V: Podman is so "Rootless"!
Guess you are here after reading through our previous post "why Docker ain't perfect" . Okay, so Docker has a few security "gotchas" and we told you all about it in detail in our last post. But hey!...we said there's another way out, didn't we? It's right here in this post!
Here's a quick recap... Docker requires a daemon (Docker daemon remember?) to run and well ....This daemon requires root privileges on the host for that.
You'll say...What's so worrisome about a process running as root? Think VIP access! In short the process has a free pass to do whatever it likes on your host system. So if the process turns rouge....well your host is going to be super vulnerable.
Another thing to remember, you won't always get root access. If you have to run your container on any large organization's server, it's pretty evident that they aren't going to hand over premium access to you. Because...
Go Rootless!
Rootless Containers! That's the new kid on the block people! The name explains itself. Its a container but doesn't need root access.
So even if you're a user with no root access. You're still allowed to run your container on the host.
If you think about it, you are adding an extra layer of security. You can at least rest assured that the host won't be compromised because some random attacker got root privileges via the containers running on the host.
The "No Root" Formula : User Namespaces
Container technology was born out of Linux concepts Namespaces and Control Groups. And rootless containers just extend upon this. Its a concept called User Namespaces.
The concept can be a bit tricky to take in especially if you are not that aware about Linux kernel terminologies. So let us simplify it a bit for you.
A King has the ultimate authority and control within the boundaries of his own kingdom. But once he crosses the border in to another kingdom, he doesn't have much power (because there's another king for that kingdom). And that's the exactly how user namespaces work.
The king is a user, his kingdom is a user namespace and the other kingdom is the host.
king = user
kingdom = user namespace
other kingdom(s) = host system
Within the user namespace, the user can be root and have all admin privileges. But outside the user namespace, the user is unprivileged and has limited access while there is a separate user who is the root (the other king)
So rootless containers are basically running within a user namespace which has a subset of all the users on the host. And out of this subset you can define any number of users to be the root. But out on the host, they may or may not be the root. If you see, you are actually allowing unprivileged users to run containers.
In the above image, User with ID 1000 is mapped as root within container X namespace and User ID 4000 is the root in Container Y namespace.
The containers X and Y are running within their namespaces and isolated from each other. If container X wants to access a file owned by the host's root, it cannot because the User ID 1000 is a non root user on the host even if its mapped as the root on the container X namespace. See? You just stepped up on the security factor by using user namespaces.
Podman to the Rescue!
So far all this talk about rootless containers seems good in theory. But how do I run rootless containers myself ? There's Podman for that!
Podman's seal is the rootless sibling to Docker's whale. Podman an Open Source framework that runs and manages containers. Rootless style! Compared to Docker, Podman is fairly new in town, but its still creating waves.
Why? Because....You got security.
You got mutliple image format support (that include docker image btw).
You got a CLI that exactly like Docker's. (Simply replace "docker" with "podman" in the command and you're done! ).
And not just that. Podman is even capable of supporting pods (group of containers sharing resources).
Sounds good huh?
So What's Different about Podman?
The biggest difference about Podman is that it uses the fork-exec concept to run containers. We just felt that you need to know about this concept.This is how it works:
Fork - Exec - Go!
See that little image up here? That folks is the fork exec model. Yes! No kidding!
- Take a process, create a new clone. That's the fork() part.
- Then take the clone or the child process, and replace its process image (that means that the child is not going to be a clone anymore and is now a different process altogether). That's exec()
- Finally allow both parent and child processes to execute independently.
Fin!
When we say that Podman use a fork exec model, it means that Podman runs as a process initially. When a container is created, the Podman process forks and forms a separate process that constitutes for the running container.
Docker vs Podman
The fork-exec method for Podman is a major factor that distinguishes Podman from Docker.
Meanwhile, Docker uses a client-server model to create containers. In other words, docker makes use of a daemon process. A container is spawned as a child of the daemon thereby making the daemon a single point of failure (we talked about this in our previous post). You don't have that in Podman. That's why we call Podman "daemonless"
You got a few notable differences that set these two apart.
The only catch that we see here is that Podman only works on Linux systems. As we said, the technology is fairly new as compared to Docker which has been in the game for a while now. We do hope support for MacOS and Windows comes up soon.
For now, if you don't have a Linux system, you can spin up a Linux VM on your local machine. We have our own GCP/AWS cloud accounts, so we usually spin up a Linux VM Server and connect to them remotely. You could try out this option too!
What's Next?
We've talked enough for you to know get a gist of Podman works. Its now time to try it out for yourself. Get a Linux system started and head to our next post where we go rootless, Podman way! Read on...