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

61–70 of 133 posts

Re: Exploring Podman: A More Secure Docker Alternative

#61

Post by righthand »

mardifoufs wrote: post #52
righthand wrote: post #48

Earlier quoted context omitted.

They invest in it because Docker is waaay out of spec with how things are done on Linux. Doing things that break the system, struggling with rootless for years, and who can miss the vendor lock-in? Podman is open and compliant and compliments k8s as well. It’s just nonsense the amount of effort developers have invested in Docker because it was first to market for easy containers.

Docker is every bit as open and not locked in as podman. Perhaps even more so as it's so widely used and doesn't require redhat specific projects around it. Are you confusing docker with docker hub?

No, I’m not confusing requiring a DockerHub account to even install Docker. Though that is an excellent example of it’s non-openness, thank you.

Re: Exploring Podman: A More Secure Docker Alternative

#62

Post by dathinab »

mardifoufs wrote: post #52
righthand wrote: post #48

Earlier quoted context omitted.

They invest in it because Docker is waaay out of spec with how things are done on Linux. Doing things that break the system, struggling with rootless for years, and who can miss the vendor lock-in? Podman is open and compliant and compliments k8s as well. It’s just nonsense the amount of effort developers have invested in Docker because it was first to market for easy containers.

Docker is every bit as open and not locked in as podman. Perhaps even more so as it's so widely used and doesn't require redhat specific projects around it. Are you confusing docker with docker hub?

> doesn't require redhat specific projects around it.

that is like saying oh no docker requires docker (company) specific projects around it

and as far as I can tell docker in recent years mainly cares about docker desktop and swarm which are less open then podman given their business model

Re: Exploring Podman: A More Secure Docker Alternative

#63

Post by madiele »

coldblues wrote: post #3

https://www.techrepublic.com/article/how-to-fix-the-docker-a... I almost got burned by this.

I've got a cryptominer in one of my personal selfhosted container of a github project meant to be used with a vpn only, due to this insecure by default choice of docker. Still salty about it...

Re: Exploring Podman: A More Secure Docker Alternative

#64

Post by notso411 »

lolinder wrote: post #21
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…

I already was defining my infrastructure with docker-compose.yml files, and found out that podman-compose has a poorly documented feature that generates systemd units. It doesn't use the now-deprecated podman feature, it writes the unit files itself, and I find the process much smoother than the podman feature anyway. To enable the feature: $ podman-compose systemd -a create-unit To register a systemd unit: $ podman-…

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

Re: Exploring Podman: A More Secure Docker Alternative

#65

Post by moondev »

zaroth wrote: post #59
Plasmoid wrote: post #16

One of the nice things about podman is that it's super easy to configure image caches. So instead of rewriting all my image references to use my local cache tool, I can just set a cache directive in podman and everything works transparently.

Can’t you run your own docker registry and enable a pull-through cache on it with just a couple commands?

Can you? Pull through cache is awesome but I have been leaning on harbor registry to implement it. Harbor is great but is a full featured registry application. Would be sweet if pull through can be quickly spun up ad hoc.

Re: Exploring Podman: A More Secure Docker Alternative

#66

Post by bravetraveler »

Modified3019 wrote: post #37
bravetraveler wrote: post #33

Earlier quoted context omitted.

I know it's a hard sell, but the 30 minutes to an hour to understand filesystem contexts and how to copy them from a good place isn't a lot It's likely to little gain. I know why people don't, but it is very accessible to those open to it The more one adheres to the FHS, the easier SELinux is

>understand filesystem contexts and how to copy them from a good place I’m not really sure what this means (I have 0 knowledge on selinux)

Some secondary reading, I've referred to FHS at times. It's the 'Filesystem Hierarchy Standard':

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

They provide guidance on how a given filesystem path should be used.

This has informed the default SELinux policies greatly; familiarity turns hassle into informed assumptions/ease.

Re: Exploring Podman: A More Secure Docker Alternative

#67

Post by lolinder »

notso411 wrote: post #64
lolinder wrote: post #21

Earlier quoted context omitted.

I already was defining my infrastructure with docker-compose.yml files, and found out that podman-compose has a poorly documented feature that generates systemd units. It doesn't use the now-deprecated podman feature, it writes the unit files itself, and I find the process much smoother than the podman feature anyway. To enable the feature: $ podman-compose systemd -a create-unit To register a systemd unit: $ podman-…

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 (podman|docker)-compose is when you have to scale up a service beyond a single node.

Re: Exploring Podman: A More Secure Docker Alternative

#68

Post by dathinab »

throwawaaarrgh wrote: post #55

Somebody should tell them Docker can run in rootless mode.

It can but:

- They by default don't.

- It's only semi officially supported. It requires non official tooling, through they link to that tooling officially in their doc. But issues specific to rootless docker seem to not be much of a priority.

- roots less docker sometimes has some slight issues, but mostly minor stuff

The fact that they can make it save to use, but do not, is a really huge red flag. And it's not the first time they didn't take security on linux not serious at all.

To clarify what I mean with "make it save", the docker user group allows easy gaining root light access, which is a huge security no-go. And the alternative is using sudo or similar all the time which also is a security no-go (if you e.g. have a dev system, it's okay for starting docker images as services, but then limitations with systemd integration make podman often a better choice here anyway). And while there are ways to make it work without a security no-go and the daemon the last time I checked they weren't out-of the box and in my opinion too brittle.

Now if you have a single user system you maintain yourself and have a single user+admin+sudo right user or similar maybe then you don't care about docker group or using sudo too often. But if it's a company managed system with reasonable security requirements it's an absolute no go.

Re: Exploring Podman: A More Secure Docker Alternative

#69

Post by lolinder »

ape4 wrote: post #54
lolinder wrote: post #21

Earlier quoted context omitted.

I already was defining my infrastructure with docker-compose.yml files, and found out that podman-compose has a poorly documented feature that generates systemd units. It doesn't use the now-deprecated podman feature, it writes the unit files itself, and I find the process much smoother than the podman feature anyway. To enable the feature: $ podman-compose systemd -a create-unit To register a systemd unit: $ podman-…

Its documented. If you just type `podman-compose` in the command line you get... usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args] [--env-file env_file] [-f file] [-p PROJECT_NAME] [--podman-path PODMAN_PATH] [--podman-args args] [--podman-pull-args args] [--podman-push-args args] [--podman-build-args args] [--podman-inspect-args args] [--podman-run-args args] [--podman-start-args args] [--podma…

Yeah, I eventually found that, but only after I finally stumbled upon someone referencing the feature in a GitHub issue.

The --help is fine documentation for the people who have already installed the tool, but it doesn't help people like OP who just want a simple way to run multiple containers as a systemd unit and don't yet know that podman-compose has a solution.

That's why I said "poorly documented" instead of "undocumented". It's there once you know where to look.

Re: Exploring Podman: A More Secure Docker Alternative

#70

Post by dathinab »

ajb wrote: post #8
CodeCompost wrote: post #7

deleted

It's supposed to be a drop-in replacement for docker - IE, you can literally alias docker to podman. I did that for a while, but ran into some command line options that weren't supported. I see they've added some k8s integration, but not sure how you see it being a k8s alternative? Maybe a minikube alternative...

it's sadly only mostly a drop-in replacement

it misses some features docker has and docker misses some features podman has and some subtle behaviour differences can lead unexpected outcomes (mostly in favor of podman doing things better)

many of the differences are irrelevant but can be an issue in scripts calling docker/podman cli

one of the more surprising discrepancies we ran into was that due to the rootless podman nature you don't need to "slowly copy the context to the daemon". In our case this lead to some slightly sub-optimal setups running just fine with podman but then taking way to long to run with docker as it copied a ton of data.

generally in my experience if you only use podman or only use docker and the "drop-in" aspect only matters for switching from one to the other permanently it works grate, but if you idk. want to use docker on some systems and podman on others it might not be the best idea

Post reply on HN