Comment by evertheylen
3 months ago
I do too, but I found it non-trivial to actually secure the podman container. I described my approach here [1]. I'm very interested to hear your approach. Any specific podman flags or do you use another tool like toolbx/distrobox?
Very interesting. I learned some new things. I didn't know about `--userns` or the flexible "bind everything" network approach!
Here's my script:
https://codeberg.org/chrisdavies/dotfiles/src/branch/main/sr...
What I do is look for a `.podman` folder, and if it exists, I use the `env` file there to explicitly bind certain ports. That does mean I have to rebuild the container if I need to add a port, so I usually bind 2 ports, and that's generally good enough for my needs.
I don't do any ssh in the container at all. I do that from the host.
The nice thing about the `.podman` folder thing is that I can be anywhere in a subfolder, type `gg pod`, and it drops me into my container (at whatever path I last accessed within the container).
No idea how secure my setup is, but I figure it's probably better than just running things unfettered on my dev box.
Yeah props to the `pasta` tool, it solves a specific problem really well.
Nice script! I considered a similar approach that's based on "magic" files in the filesystem before, but it was difficult to get the security right. In your case I believe a malicious script can just overwrite .podman/env and it will be sourced by the host the next time you start the container.
I'm happy to discuss this more, feel free to reach out at evertheylen@gmail.com. I'm particularly interested in trying automated ways to try to break out of a container (like https://github.com/brompwnie/botb), this would benefit any containerization project.