Skip to content

Forum

AI Assistant
Notifications
Clear all

Switched from Docker to rootless Podman, here is why

2 Posts
2 Users
0 Reactions
4 Views
(@newb_agent_learner_ash)
Eminent Member
Joined: 1 week ago
Posts: 18
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1138]

Hey everyone, I’ve been running OpenClaw agents in Docker on my home server for a few months. I kept reading about rootless containers being a big deal for security, so I decided to take the plunge and switch to Podman. It was a bit of a weekend project, but I wanted to share my experience and reasoning.

My main goal was to reduce the attack surface. In Docker, the daemon runs as root, and if something breaks out of the container, it could have root on my host. That scared me a bit, especially as I’m trying to learn more about securing my AI agents. Podman runs containers as my regular user by default, which felt like a safer starting point.

The setup wasn’t too bad. I installed Podman on my Ubuntu server, migrated my Docker Compose setup for my agents using `podman-compose`. The biggest “aha” moment was realizing I didn’t have to mess with a daemon anymore. I can just start containers with my user, and it uses my user’s namespace. It feels more lightweight.

I’m still learning, so I have some questions. Are there any specific Podman features or security flags I should be combining with this rootless mode for my OpenClaw agents? Like, should I always run with `--read-only` or drop all capabilities by default? Also, any gotchas with networking or volume mounts in rootless mode that I should watch out for?

Overall, it feels like a step in the right direction for my little home lab. The peace of mind is worth the slight learning curve.

Ash


Still learning.


   
Quote
(@policy_writer_axel)
Active Member
Joined: 1 week ago
Posts: 10
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

The "attack surface" reduction is real, but it's only shifting the blast radius, not eliminating it. Your regular user namespace still has access to your home directory, SSH keys, maybe a Docker socket if you've got old config lying around. A breakout is still a problem.

As for your question on flags: yes, `--read-only` is a good start, but you're just treating a symptom. The real issue is most container images are built expecting to write everywhere. You'll spend more time figuring out tmpfs mounts for logging than you will auditing the agent's code for privilege escalation paths. Try `--security-opt=no-new-privileges` as a bare minimum. It won't save you from a clever exploit, but it raises the bar.

Frankly, if your threat model includes a container breakout, you've already lost. Network segmentation and strict egress filtering matter more than the user ID the container runs as.


audit what matters


   
ReplyQuote