Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring Podman: A More Secure Docker Alternative

betterstack.com

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Exploring Podman: A More Secure Docker Alternative

#81

Post by morelisp »

lolinder wrote: post #67
notso411 wrote: post #64

Earlier quoted context omitted.

I thought docker compose was for local dev only and not meant to be used for production workloads?

I'm using podman-compose for my homelab, which is obviously fine. But even for small-scale single-node production use cases, I suspect that podman-compose with systemd doesn't have the same concerns as docker-compose does. Since you're registering the workload with systemd, it'll restart with the node as easily as any other service, and rootless containers are a big win for security. Where you can't keep using (podma…

You can keep using x-compose on several nodes, you just need e.g. ansible or salt on top of it. For many things this is still a local maximum compared to a K8s cluster or "just ssh in'.

Re: Exploring Podman: A More Secure Docker Alternative

#82

Post by tjay1 »

VoidWhisperer wrote: post #78
xyst wrote: post #49

I had some issues with podman working on my m1 mac about 1-2 yrs ago. I’ll give it a shot again. Looks like it has matured very fast.

I've had issues as recently as this week with podman on an m1 laptop - the container would start but after a short time would freeze completely and couldn't even be killed - only solution i found was to restart my laptop. Eventually, I gave up and went back to using docker.

Same, I tried it on Thursday, I would recommend people on M1 Macs to stay well clear of podman for now.

Re: Exploring Podman: A More Secure Docker Alternative

#83

Post by mardifoufs »

righthand wrote: post #80
mardifoufs wrote: post #71

Earlier quoted context omitted.

What? That's just completely wrong. Even for docker desktop (which is completely different from docker engine) you don't need an account

It appears they have since reverted the decision in 2020 but it used to require logging in for Docker Engine: https://github.com/docker/docs/issues/6910 I did not know this as I stopped using Docker long ago.

Oh yeah to be clear, I absolutely agree that docker desktop as a whole is a mess especially since they keep introducing more ways to tie it up to docker hub etc. I wouldn't use it unless I'm on windows. So yes, avoid docker desktop but docker (the engine) itself is thankfully completely separate from docker desktop.

Re: Exploring Podman: A More Secure Docker Alternative

#84

Post by zamalek »

freedomben wrote: post #44

I almost never see what is IMHO the killer feature of Podman touted as a reason to prefer it over Docker: Docker mangles your network config. It is a nightmare trying to run Docker and KVM virtual machines with bridges at the same time. Podman on the other hand plays very nice OOTB. I've also had a lot of VPNs break and/or be broken by Docker. I don't know much about the way podman does networking, but whatever it is…

Buildah (which may well work with Docker, but is a Podman peer) is the killer feature in my opinion. Dockerfiles are unadulterated shite. One of my pet peeves is "bored developers" writing DSLs/programming languages (especially in YAML, but that isn't the case here) when an off-the-shelf language would have done. Dockerfiles are a genuinely fantastic example of why this nonsense needs to end.

To see why, look at Buildah without `bud`. Instead of a silly DSL that becomes annoying the second your use-case veers an inch off the happy path, you can use Bash, or Fish, or whatever it is that you want.

These types of bad decisions carry the into the rest of the Docker ecosystem. DCS and it's (perpetually incomplete) replacement are yet more examples: instead of using established signing protocols (like Cosign does) they had the desire to build an obnoxiously complex and hard to automate (especially key rotation) system.

Re: Exploring Podman: A More Secure Docker Alternative

#85

Post by zamalek »

jazzyjackson wrote: post #75
steveBK123 wrote: post #43

Earlier quoted context omitted.

I always find it amusing that the cutting edge future of serverless/containers/etc was built on the back of running a bunch of stuff as root. Very cool.

I'm trying to get up to speed with docker atm, is it the applications inside the container that are typically running as root (which people are careless about from a "whats the worst that can happen" attitude?) or is the typical pattern that people are running the docker host process as root (maybe in order to allow the host to expose ports at 80/443 without some reverse proxy/firewall in front of it?)

With the default Docker installation, root in a container is root on the host. uid 1234 is uid 1234 on the host.

With Podman (and Docker rootless), subuids/subgids[1] are _usually_ used. Root in the container is root only within the Linux user namespace. You can map users to real users, including yourself and root - which is how distrobox works, but it's secure by default: your subordinate users can't even access your resources.

The primary limitation of rootless is networking, the kernel doesn't have a built-in way to do rootless networking in the way that you want for containers.

[1]: https://www.man7.org/linux/man-pages/man5/subuid.5.html

Re: Exploring Podman: A More Secure Docker Alternative

#86

Post by oasisaimlessly »

Can anyone tell me why neither Docker nor Podman allow you to dynamically modify forwarded ports? It would allow zero-downtime updates of containers (starting new container, wait for it to be healthy, update port forwards, stop old container).

And no, reverse proxies do not solve this problem; lots of protocols (e.g. SSH) have no equivalent to X-Forwarded-For for identifying the remote host.

Re: Exploring Podman: A More Secure Docker Alternative

#87

Post by tahnyall »

freedomben wrote: post #44

I almost never see what is IMHO the killer feature of Podman touted as a reason to prefer it over Docker: Docker mangles your network config. It is a nightmare trying to run Docker and KVM virtual machines with bridges at the same time. Podman on the other hand plays very nice OOTB. I've also had a lot of VPNs break and/or be broken by Docker. I don't know much about the way podman does networking, but whatever it is…

> It is a nightmare trying to run Docker and KVM virtual machines with bridges at the same time.

I'm doing it right now, no nightmares, just works, odd.

Re: Exploring Podman: A More Secure Docker Alternative

#89

Post by steveBK123 »

zamalek wrote: post #85
jazzyjackson wrote: post #75

Earlier quoted context omitted.

I'm trying to get up to speed with docker atm, is it the applications inside the container that are typically running as root (which people are careless about from a "whats the worst that can happen" attitude?) or is the typical pattern that people are running the docker host process as root (maybe in order to allow the host to expose ports at 80/443 without some reverse proxy/firewall in front of it?)

With the default Docker installation, root in a container is root on the host. uid 1234 is uid 1234 on the host. With Podman (and Docker rootless), subuids/subgids[1] are _usually_ used. Root in the container is root only within the Linux user namespace. You can map users to real users, including yourself and root - which is how distrobox works, but it's secure by default: your subordinate users can't even access you…

Yes the default is insane. Orgs that took away root from devs two decades ago let some of this stuff slip through..

Re: Exploring Podman: A More Secure Docker Alternative

#90

Post by sph »

emerongi wrote: post #11
tekeous wrote: post #6

Podman was good when it supported systemd unit files, so I could auto start and auto update containers, even entire pods with systemd. Then they removed that in favor of Quadlet. Now in order to do a single container I can do a unit file, but for a pod, I need to use a Kubernetes cluster definition. Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable…

> Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable to access mapped directories. Add the following to containers.conf if you don't want to deal with it: [containers] label=false If you don't like podman's default security level, there is usually a way to turn things off.

The only times I had issues with SELinux and podman, it was because I forgot to add the z flag to the volume:

    podman run -v .:/app:z image
This only happens locally as files in your home have strict security rules, never had any issue on a CentOS server.
Post reply on HN