Learn Podman - Rootless & Daemonless Mode

#Introduction

Episode 4 covered images and registries. Episode 5 returns to the security foundation promised since episode 1: the rootless and daemonless mode that is Podman's main differentiator. You'll learn how Podman runs as a regular user, how resources are limited, how networking works without root, and how podman machine runs all of that on macOS and Windows.

#Rootless Mode

Rootless mode means all container operations run as a regular user — no sudo and no root daemon. This is what makes Podman safer: no container process holds full access to the host.

#User Namespace Remapping

The technical key is the user namespace. Podman maps user identities inside the container to a dedicated UID range on the host. A process inside the container believes it is running as root (UID 0), but on the host that UID is mapped to a regular user with a shifted number — for example UID 100000. If a container manages to escape its isolation, the privileges gained remain those of a regular user, not root.

This mechanism is controlled through the containers.conf configuration:

User namespace in containers.conf

[containers]
userns = "auto"

userns = "auto" makes Podman automatically allocate a UID range for each container. This value is already the default and is the main reason why podman run never needs sudo.

#Resource Limits

Without sudo, resource limits can still be enforced through cgroups v2, and Podman provides direct flags for it:

podman run -d --name api --memory 512m --cpus 0.5 nginx:latest
podman stats api

--memory 512m limits the container's memory, --cpus 0.5 limits CPU usage, and podman stats monitors the results. These limits work within the user's own cgroup — so they don't require root privileges.

#Limitations to Be Aware Of

Rootless mode changes some assumptions compared to root mode:

• Low ports can't be opened directly — ports below 1024, like port 80 or 443, require root. Instead, map to a high port or set up a proxy.
• Device access is limited — rootless containers can't access certain hardware without extra configuration.
• Certain mount types are restricted — some filesystem types can't be mounted in a user namespace.

That doesn't mean rootless can't be used in production — many deployments intentionally use rootless. But understanding these limitations saves you from confusion when a container behaves differently between a root host and a rootless one.

#Networking Without Root: slirp4netns and pasta

Rootless containers can't create a network bridge the way root containers can. Instead, Podman uses user-space network translation:

• slirp4netns — a user-space network translator that emulates TCP and UDP protocols without root privileges.
• pasta — a newer approach that also runs without root, with more efficient port forwarding.

To see which network backend is active, run podman info — the host section of the output shows the backend.

#Podman Machine

On macOS and Windows, Podman can't use the Linux kernel directly. The solution is podman machine: a lightweight virtual machine that Podman itself runs and manages.

#Initialization and Startup

The basic flow is two steps:

podman machine init
podman machine start

podman machine init creates a new VM in the background; podman machine start powers it on and configures the connection. Once the VM is running, all podman commands are forwarded automatically to the VM — you don't need to worry about the details.

#Configuring Machine Resources

The VM created by podman machine init uses default resource values. If you need a bigger VM, specify it at initialization:

podman machine init --cpus 2 --memory 2048 --disk-size 40
podman machine start

--cpus 2 provides two cores, --memory 2048 provides 2 GB of RAM, and --disk-size 40 provides 40 GB of disk space. Adjust them according to the needs of the applications you'll run inside the VM.

#Managing Machines

Some management commands you'll use often:

podman machine list
podman machine ssh

The podman machine ssh line opens a shell inside the VM — useful for checking things running on the VM side. Ports published by containers in the VM are automatically forwarded to the host, so you can still access applications from your browser on macOS or Windows. Although the VM adds a little overhead for heavy workloads, for daily development podman machine feels almost identical to native Podman on Linux.

#Closing

Episode 5 completes Podman's security layer: user namespace remapping that runs containers as a regular user, resource limits via cgroups without sudo, rootless networking via slirp4netns and pasta, and podman machine that brings Podman to macOS and Windows through a lightweight VM.

The key points to take home:

• Rootless isn't just a mode — it's a user-namespace-based security architecture.
• Resources can still be limited without sudo — --memory and --cpus work through cgroups v2.
• Rootless networking runs in user-space — pasta and slirp4netns replace the kernel bridge.
• podman machine init and podman machine start are the gateway to Podman on macOS and Windows.

The next episode, Episode 6, introduces the most distinctive concept in Podman: pods — a group of containers that share a network namespace, Kubernetes-style. You'll create a pod, place containers inside it, and start thinking in the Kubernetes mindset.