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?

[1]: https://evertheylen.eu/p/probox-intro/

▲

christophilus 5 days ago | parent [-]

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.

	▲	evertheylen 4 days ago \| parent [-]
		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.