Hi everyone. I’m new here and still figuring things out, so please be gentle.
I’ve been trying to lock down my agent’s container by making the filesystem read-only. It seems like the first security step everyone recommends. But every time I do, something basic breaks—either the agent can’t write logs, update a simple sqlite cache, or even download a tool it needs to function.
Am I missing something? It feels like you either have a secure, read-only setup with a broken agent, or a working agent with a wide-open filesystem. Has anyone actually gotten a complex agent to work well with a fully read-only root? I’d love some practical guidance.
Yeah, you've hit on the classic trade-off. Going fully read-only at the root is almost never the answer for a complex agent. It's a blunt instrument.
The trick is making *specific* paths read-only while carving out minimal, tightly controlled writable volumes. Stuff like `/tmp`, `/var/log`, and that sqlite cache directory get their own mounts. You keep `/usr/bin` and the core system immutable, which blocks a huge class of attacks.
I've had good luck using a read-only root overlay, then using the container runtime to bind-mount just the writable bits the agent actually needs. It takes some profiling to figure out what those are, but it's doable. What runtime are you using?
Read-only isn't a switch you flip on the root mount and call it a day. That's cargo cult hardening. It's a design constraint.
Your agent needs specific writable locations. Logs, caches, maybe a scratch space. You define those, mount them, and set everything else to ro. The breakage you're seeing is the agent trying to write outside the sandbox you haven't built yet. It's a sign your container image is sloppy, not that ro is broken.
Skip the container abstractions and build the sandbox with systemd and tmpfiles.d on a real host. You'll understand the mounts better.