I’m moving to a new machine soon and want to re-evaluate some security practices while I’m doing it. My current server is debian with all apps containerized in docker with root. I’d like to harden some stuff, especially vaultwarden but I’m concerned about transitioning to podman while using complex docker setups like nextcloud-aio. Do you have experience hardening your containers by switching? Is it worth it? How long is a piece of string?

15 points

I use podman almost exclusively at this point. I like having the rootless containers and secrets management. If you’re on Debian, though, I strongly suggest pulling podman from Trixie. The version in Bookworm is very out of date and there’s been a lot of fixes since then.

permalink
report
reply
7 points

Podman not because of security but because of quadlets (systemd integration). Makes setting up and managing container services a breeze.

permalink
report
reply
3 points

Yeah quadlets are pretty cool. I have them organized into folders for each pod. podman auto-update is also another pretty nice feature. I don’t use the systemd timer for auto-update. Instead I just do podman auto-update --dry-run to check for updates and update my quadlet files and configs if any changes are required then I run the updates with podman auto-update.

permalink
report
parent
reply

I started with rootless podman when I set up All My Things, and I have never had an issue with either maintaining or running it. Most Docker instructions are transposable, except that podman doesn’t assume everything lives as dockerhub and you always have to specify the host. I’ve run into a couple of edge cases where arguments are not 1:1 and I’ve had to dig to figure out what the argument is on podman. I don’t know if I’m actually more secure, but I feel more secure, and I really like not having the docker service running as root in the background. All in all, I think my experience with rootless podman has been better than my experience with docker, but at this point, I’ve had far more experience with podman.

Podman-compose gives me indigestion, but docker-compose didn’t exist or wasn’t yet common back when I used docker; and by the time I was setting up a homelab, I’d already settled on podman. So I just don’t use it most of the time, and wire things up by hand when necessary. Again, I don’t know whether that’s just me, or if podman-compose is more flaky than docker-compose. Podman-compose is certainly much younger and less battle-tested. So is podman but, as I said, I’ve been happy with it.

I really like running containers as separate users without that daemon - I can’t even remember what about the daemon was causing me grief; I think it may have been the fact that it was always running and consuming resources, even when I wasn’t running a container, which isn’t a consideration for a homelab. However, I’d rather deeply know one tool than kind of know two that do the same thing, and since I run containers in several different situations, using podman everywhere allows me to exploit the intimacy I wouldn’t have if I were using docker in some places and podman in others.

permalink
report
reply
1 point

I make extensive use of compose in my own server so I’m assuming I’ll need to transition to systemd confs. Do you run those or do you run everything by podman CLI?

permalink
report
parent
reply

Yeah, I use systemd for the self-host stuff, but you should be able to use docker-compose files with podman-compose with no, or only minor, changes. Theoretically. If you’re comfortable with compose, you may have more luck. I didn’t have a lot of experience with docker-compose, and so when there’s hiccups I tend to just give up and do it manually, because it works just fine that way, too, and it’s easier (for me).

permalink
report
parent
reply
14 points

I’m running podman and podman-compose with no problem. And I’m happy. At first I was confused by the uid and gid mapping the containers have, but you’ll get used to it.

This are some notes I took, please don’t take all of it for the right choice.

Podman-Stuff

https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md

storage.conf

To use the fuse-overlay driver, the storage must be configured:

.config/containers/storage.conf

[storage]
  driver = "overlay"
  runroot = "/run/user/1000"
  graphroot = "/home/<user>/.local/share/containers/storage"
  [storage.options]
    mount_program = "/usr/bin/fuse-overlayfs"

Lingering (running services without login / after logout)

https://github.com/containers/podman/issues/12001

https://unix.stackexchange.com/questions/462845/how-to-apply-lingering-immedeately#462867

sudo loginctl enable-linger <user>
permalink
report
reply
2 points

Do you need to set lingering for all container users you set up? Does it restart all services in your compose files without issue?

permalink
report
parent
reply
2 points

Yes all users that have containers running, that should keep running need lingering.

The Services do not restart themself. I have cronjob that executes podman start --all at reboot for my “podman user”.

permalink
report
parent
reply
5 points

Podman

  • rootless by default
  • daemonless
  • integration with systemd, made even easier by podman-generate-systemd
  • no third-party APT repository required, follows the same lifecycle as my LTS (Debian) distro
  • podman and docker command-line are 100% compatible for my use cases
permalink
report
reply
3 points
*

podman-generate-systemd is outdated. The currently supported way to run podman containers using systemd services would be Quadlet files.

https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

Edit: I just saw that you use debian so idk if Quadlets are a thing with the podman version on debian.

permalink
report
parent
reply

Selfhosted

!selfhosted@lemmy.world

Create post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

Community stats

  • 5K

    Monthly active users

  • 3.5K

    Posts

  • 77K

    Comments