[HN Gopher] Exploring Podman: A More Secure Docker Alternative
___________________________________________________________________
Exploring Podman: A More Secure Docker Alternative
Author : sacrosanct
Score : 246 points
Date : 2024-01-13 17:00 UTC (5 hours ago)
(HTM) web link (betterstack.com)
(TXT) w3m dump (betterstack.com)
| coldblues wrote:
| https://www.techrepublic.com/article/how-to-fix-the-docker-a...
|
| I almost got burned by this.
| sureglymop wrote:
| Docker even just messes with iptables in its default
| configuration/installation. It's always been a pain point
| especially if one wants to use the newer nftables.
| jamesu wrote:
| Speaking of networking issues, one big problem I ran into was
| running out of memory for network devices when using a nested
| setup (requiring a system restart to fix). Would have been a
| great lxc alternative otherwise.
| madiele wrote:
| 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...
| bootsmann wrote:
| Glad that podman is getting more traction tbh, too many tools are
| built with the assumption that people add the sudo docker group
| which break if you have any kind of security conscious docker
| setup (such as not blindly giving it root access).
| steveBK123 wrote:
| 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.
| jazzyjackson wrote:
| 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?)
| zamalek wrote:
| 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
| steveBK123 wrote:
| Yes the default is insane. Orgs that took away root from
| devs two decades ago let some of this stuff slip
| through..
| tekeous wrote:
| 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 to access
| mapped directories.
|
| So what is it, Podman? Should I just use Kubernetes? Should I
| just make dedicated directories for everything instead of mapping
| logical places for things?
| rcarmo wrote:
| This. Quadlet wasn't really needed and just complicated matters
| for me, so I went back to docker-compose.
| emerongi wrote:
| > 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.
| sph wrote:
| 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.
| bonzini wrote:
| > unlike Docker their containers bow to SELinux definitions,
|
| That's a bug in docker. If your system isn't configured for
| SELinux, disable it.
|
| Also the systemd files generated by podman-generate-systemd are
| just executing "podman start containername", you can write them
| on your own easily but (unlike e.g. docker-composr) the
| containers are black boxes pretty much.
|
| The advantage of quadlet is that the definition of the
| container is declared in the .container file; before I used to
| write the podman run command line manually in a handwritten
| systemd unit, and quadlet is a big improvement in that respect
| and can be an alternative to docker-compose (with advantages
| and disadvantages).
| INTPenis wrote:
| >That's a bug in docker. If your system isn't configured for
| SELinux, disable it.
|
| I feel obligated to say that you should set it to permissive
| mode, never disable SElinux. sudo
| setenforce 0
| bravetraveler wrote:
| 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
| Modified3019 wrote:
| >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)
| bravetraveler wrote:
| edit: Apologies for the wall. I think I finally landed on
| a decent mix after many edits. I'm finished now, lol.
|
| SELinux has a bit of a well deserved reputation... but I,
| a fairly silly person, have managed to work with it
|
| This video likely explains things far better than I can
| in this post:
|
| https://www.youtube.com/watch?v=_WOKRaM-HI4
|
| I'll probably fail with specifics, where they certainly
| do a better job.
|
| So. First it's important to know SELinux runs in one of
| two modes: * A targeted mode where
| well-known/accounted-for things are protected. For
| example, nginx * A more draconian mode where
| *everything* is protected
|
| People often present the first _[default]_ mode as if it
| were the second.
|
| The protection is based on policies that say _' things
| with this label/at this path are allowed to do XYZ'_.
|
| It's _very_ focused on filesystem paths and what
| _relevant applications_ try to do.
|
| It's entirely manageable, but admittedly, complicated.
| Without practicing the words I can't express them.
|
| Most people having trouble with SELinux are defying some
| convention. For example: placing application scratch data
| in _' /etc_'.
|
| Policy management is a complicated topic.
|
| The policy can be amended in cases where the standard
| doesn't apply; I won't cast judgement - sometimes it's a
| good idea, sometimes not.
|
| Another way to handle this is to copy the label from one
| path and apply it to the one your application
| requires/customizes. This is less durable than leaning on
| the policy.
|
| It acts as a sort of central DB... the goal is to make
| things such that the policy stores all of the contexts so
| the files/dirs can have "labels" applied for SELinux
| bravetraveler wrote:
| 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.ht
| ml
|
| 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.
| sph wrote:
| I have been doing Linux sysadmin for 20 years and I just
| stopped trying to understand SELinux. It looks and feels
| like an abomination borne out of some IBM or other
| antediluvian corporate UNIX system for programmers
| wearing suit and tie.
|
| Terrible documentation, terrible mental model, terrible
| CLI UX, terrible error messages.
|
| I run Fedora and SELinux is working well enough, but it's
| a piece of machinery I can't wait to see replaced,
| however useful people swear it is.
| bonzini wrote:
| I meant disable labeling in podman. :)
| nineteen999 wrote:
| Only if you want it back in enforcing mode after the next
| reboot. If you want to make the change permanent, you need
| to set the following in /etc/selinux/config as well:
|
| SELINUX=permissive
| Kwpolska wrote:
| You should set it to permissive mode if you think you will
| ever need to re-enable that trainwreck.
| hinkley wrote:
| I've been complaining about our OPs people pushing Colima over
| podman and now you're making me think my podman info is
| outdated. Ouch.
| asmor wrote:
| `podman generate systemd` is still there, and I see no reason
| you couldn't use it. it's just a bunch of podman commands
| wrapped in a unit file, no magic.
|
| feels like a lot more cruft than quadlets to me though.
| lolinder wrote:
| 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-compose
| systemd -a register $ systemctl --user enable --now
| "podman-compose@$PROJECT_NAME"
|
| Updating looks like this: $ podman-compose
| pull $ systemctl --user restart "podman-
| compose@$PROJECT_NAME"
|
| ($PROJECT_NAME is usually the directory name.)
|
| Source code for the feature is here if you care to inspect it:
|
| https://github.com/containers/podman-compose/blob/f6dbce3618...
|
| Admittedly, I'm still on podman 4.3.1, but I don't see any
| reason why this would stop working in later versions of podman.
| kccqzy wrote:
| That's much more elegant than my hacky hand-written systemd
| unit (one-shot, remain after exit) to start podman
| containers.
| ape4 wrote:
| 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]
| [--podman-stop-args args] [--podman-rm-args args]
| [--podman-volume-args args] [--no-ansi] [--no-cleanup]
| [--dry-run] {help,version,wait,
| systemd,pull,push,build,up,down,ps,run,exec,start,stop,restar
| t,logs,config,port,pause,unpause,kill}
| ... command: {help,version,wait,sy
| stemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,
| logs,config,port,pause,unpause,kill} ...
| systemd create systemd unit file and register its
| compose stacks
| When first installed type `sudo podman-compose systemd -a
| create-unit` later you
| can add a compose stack by running `podman-compose systemd -a
| register` then you can
| start/stop your stack with `systemctl --user start podman-
| compose@<PROJ>`
| lolinder wrote:
| 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.
| notso411 wrote:
| I thought docker compose was for local dev only and not meant
| to be used for production workloads?
| lolinder wrote:
| 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.
| morelisp wrote:
| 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'.
| INTPenis wrote:
| What are you talking about? Quadlet generates ordinary systemd
| service units with podman commands. Isn't that what you were
| using?
|
| It's just a simplified layer ontop of those old systemd units.
| madspindel wrote:
| You can generate Kubernetes yaml files with podman kube
| generate. Then you can use systemd to run the generated files:
| https://www.redhat.com/sysadmin/kubernetes-workloads-podman-...
| BossingAround wrote:
| > Plus, unlike Docker their containers bow to SELinux
| definitions
|
| Isn't that great? You want SELinux if you deploy containers on
| prod.
|
| > I have repeatedly struggled with containers unable to access
| mapped directories.
|
| Use the `z` or `Z` flag, e.g. `podman run -v mydir:podman_dir:z
| nginx` to get SELinux labels updated automatically (and
| temporarily) by podman.
| bravetraveler wrote:
| Long time fan, yet - agreed.
|
| I keep forgetting this transition happened until I try to _'
| podman generate systemd [...]'_
|
| This is rare because I wrote an Ansible role to do this in a
| way that feels nice.
|
| Anyway, it really feels like podman lost the mark. I've already
| subscribed to the unit file maintenance/relationship planning
| thing. Just let me use the generator. I don't care about
| Quadlets or how they might be better.
| freedomben wrote:
| That was a cool feature (I didn't realize it was gone, that's
| unfortunate), although I felt the generated code wasn't super
| great, and if the container is stateless (excepting what's
| stored in volumes of course) then it's so simple to write your
| own systemd unit file that I just do that now. I wrote it once
| and pretty much just copy/paste it when needed, changing the
| podman run command for image names, port numbers, volumes, etc.
| For example, here's what I use for Jellyfin. Just drop at
| `/etc/systemd/system/jellyfin.service`:
| [Unit] Description=Jellfyin
| After=NetworkManager-wait-online.service
| [Service] Restart=always
| ExecStart=/usr/bin/podman run --rm --volume
| '/srv/jellyfin/config:/config:Z' --volume
| '/srv/jellyfin/cache:/cache:Z' --volume '/media/media:/media:Z'
| --publish '8096:8096' --publish '8920:8920' --publish
| '1901:1900/udp' --publish '7359:7359/udp' --name 'jellyfin'
| 'docker.io/jellyfin/jellyfin:latest'
| ExecStop=/usr/bin/podman stop -t 5 jellyfin ; /usr/bin/podman
| rm -f jellyfin [Install]
| WantedBy=local.target
|
| Note: You can also just `s/podman/docker/g` and reuse the same
| service file with docker, which is really convenient for
| systems where you have no choice
| runiq wrote:
| AFAIK podman either already supports pods in quadlet container
| files, or will in the near future.
| https://github.com/containers/podman/pull/20762
| starttoaster wrote:
| > So what is it, Podman? Should I just use Kubernetes?
|
| If you're talking about a production system for any business
| larger than a 10 person tech startup; yeah, probably.
| Alternatively there's Docker Swarm and Hashicorp Nomad. Though
| Swarm is not nearly as flexible, it's just easy to use. And
| Nomad... well, let's just say I've been paying closer attention
| to Hashicorp's build processes in their open source repos like
| Packer and Vault as of late and they do some stuff that seems
| shady to me so use at your own risk.
| CodeCompost wrote:
| deleted
| ajb wrote:
| 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...
| dathinab wrote:
| 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
| madjam002 wrote:
| Maybe you're thinking of something else, because Podman is
| mostly a replacement for Docker and shares most of the same
| command line, not k8s
| dkarras wrote:
| umm what gave you that idea?
| politelemon wrote:
| Sounds good, I like their security first approach and some of the
| decisions they've made, going for secure defaults out of the box,
| and that it works with docker compose. I wonder if podman gains
| enough traction, at some point, they decide to go their own way
| with regards to the commands and the yml, because right now it
| seems to be a tool that 'hangs on to' docker and docker's compose
| file format.
|
| It would be good to have a swarm alternative in podman, it seems
| like k8s is a crutch for lack of orchestration. With their good
| security hat on they could probably come up with a sane, simple
| way of running containers at small scales without having to dive
| into a PhD in k8s which doesn't have secure defaults out of the
| box, while maintaining compatibility with docker compose format.
|
| Anyway that's a good intro thanks for sharing, I'll be trying it
| later.
| qwertox wrote:
| I have such a huge arsenal of custom tools to manage Docker, that
| I envy Podman users because I can't move to it because of this
| technical debt.
|
| I just keep hoping that Docker isn't that bad and is a good
| alternative to Podman, because I've read mostly good things about
| the it, while Docker usually gets dragged through the dirt.
| pydry wrote:
| Podman itself is good but on the tooling side it falls down.
|
| Docker tooling tends to work with podman but you have to do a
| bunch of stuff like run a server to imitate docker. At that
| point why bother?
| Plasmoid wrote:
| 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.
| zaroth wrote:
| Can't you run your own docker registry and enable a pull-
| through cache on it with just a couple commands?
| moondev wrote:
| 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.
| INTPenis wrote:
| As a certified RHEL engineer I have been using Podman for years
| already.
|
| To be perfectly honest I do enjoy it for all my personal
| container use. But at work I still use docker for our developers.
| There is so far nothing I can offer our developers that can match
| docker compose in simplicity.
|
| We even use buildah in CI pipelines when we make container
| images, but specifically for developer end users docker compose
| is still dominant.
| BossingAround wrote:
| You should be able to use podman with docker compose though
| (https://www.redhat.com/sysadmin/podman-docker-compose)
| geerlingguy wrote:
| Should, but there are still edge cases where people use weird
| edge features of Docker's implementation that don't always
| work out of the box with Podman (it's a lot better now,
| though, and most of my compose files are fine either way).
| BossingAround wrote:
| I still don't really understand why Red Hat invests into creating
| a Docker alternative, but I really like it. Podman does pretty
| much everything Docker does, but it has more features (e.g. pods)
| or the way Podman does it tends to be better (e.g. daemonless
| container spawning process).
|
| The main issue to a common developer would be Docker compose I
| suppose, which if you use simple compose files, there's actually
| a podman-compose script that attempts to be compatible with the
| Docker compose spec.
|
| There's also using Podman as a backend for docker-compose [1].
| Overall, in 2024, I see no reason using Docker at least on Linux
| boxes. Not sure how Podman fares on macOS or Windows.
|
| [1] https://www.redhat.com/sysadmin/podman-docker-compose
| koito17 wrote:
| I use Podman on Mac OS. I've found the experience better than
| Docker for the most part, especially when it comes to
| supporting older versions of Mac OS. The only major downside of
| Podman on Mac OS is that you cant use the host network in a
| container, but people will rarely want to use the host network
| in a container anyway. This is something to keep in mind if you
| want to experiment with network things in a container and want
| to retain the same hostname and IP address of your host,
| however. I manage to work around this limitation anyway.
| lolinder wrote:
| > The only major downside of Podman on Mac OS is that you
| cant use the host network in a container
|
| And this isn't even a Podman-specific issue, it's true of
| Docker Desktop as well [0]:
|
| > The host networking driver only works on Linux hosts, and
| is not supported on Docker Desktop for Mac, Docker Desktop
| for Windows, or Docker EE for Windows Server.
|
| [0] https://docs.docker.com/network/drivers/host/
| windexh8er wrote:
| > I see no reason using Docker at least on Linux boxes. Not
| sure how Podman fares on macOS or Windows.
|
| I hope the majority doesn't end up with your point of view.
| Docker is not RedHat/IBM. If Docker goes away RedHat gets to
| continue to push their corporate agenda with a heavier hand.
| There are some advantages to Podman, but there are also some
| things that have not been executed well in RedHat's mission to
| replace all things Docker. If you look at the history of how
| RedHat approached the container space they could have
| contributed, and improved, a lot of projects they ultimately
| wasted time and effort on. RedHat isn't a company that has an
| agenda of doing right by the customer and that's why you should
| consider what you hope for from a bigger picture perspective.
| dathinab wrote:
| > they could have contributed, and improved, a lot of
| projects
|
| they tried to work with docker, it didn't work out, that is
| why we have podman
|
| and given the headache "securely" using docker is I'm really
| happy that they did
| jzb wrote:
| Red Hat had ample reason to develop Podman when they started
| the project and no reason now to abandon it.
|
| Red Hat tried to work with Docker, but it didn't go well.
| Docker also shot itself in the foot trying to push Swarm over
| Kubernetes and a bunch of other silliness until they had some
| serious management/leadership changes.
|
| Podman, IIRC, is 100% FOSS. Not sure you can say the same for
| Docker. If Red Hat gets stupid with Podman, the rest the
| community can pick it up and carry on under a new name. Not
| true of Docker. If Docker gets bought by, say Broadcom
| tomorrow, the community can only fork the bits that are open.
| righthand wrote:
| 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.
| mardifoufs wrote:
| 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?
| righthand wrote:
| 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.
| mardifoufs wrote:
| What? That's just completely wrong. Even for docker
| desktop (which is completely different from docker
| engine) you don't need an account
| righthand wrote:
| 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.
| mardifoufs wrote:
| 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.
| dathinab wrote:
| > 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
| mardifoufs wrote:
| Docker still sees a ton of development. I wouldn't be
| surprised if it sees more dev than podman.
|
| And my point was more so that podman is obviously
| designed around the rhel ecosystem. I'm not saying it's
| closed! Just that even if we were to (wrongly) argue that
| one of the two is more "locked in", it's clearly podman.
| Docker is so much more widely used, ported, is basically
| as completely "non locked in" as it could be.
|
| The only possible "lock in" is maybe the docker images
| namespace defaulting to docker hub but imo that's trivial
| and basically more of an early design choice that can't
| be reverted.
|
| By all means, we can argue about technical differences
| but the often repeated argument about docker being less
| open than podman or whatever is just not true
| jzb wrote:
| It's really not if you're talking about Docker Desktop or
| any of the commercial products:
| https://docs.docker.com/subscription/desktop-license/
|
| Podman Desktop is completely open.
| mardifoufs wrote:
| Well sure, then let's talk about podman desktop. I'm
| pretty sure the discussion was around docker itself, but
| maybe I got confused... Because otherwise you can just
| use other tools rather that docker desktop to manage
| docker containers (eg rancher desktop, which is also open
| source).
| dathinab wrote:
| docker isn't really struggeling with rootles, it works with
| rootless since a long time
|
| they just never bothered making it the default or officially
| supporting it
|
| which in context with how they acted about other security
| problems int the past tells a lot about how serious the
| docker company takes security on linux
| dathinab wrote:
| > I still don't really understand why Red Hat invests into
| creating a Docker alternative, but I really like it.
|
| They originally tried to work together with docker to fix
| various issues (e.g. systemd compatibility for certain use
| case) which had popped up in the past but this turned out not
| very fruit full.
|
| If you combine this that docker had and still has a uncanny
| amount of security issues(1) and docker like containers/images
| being very widely used by developers they had very little
| choice then to create their own implementation which is more in
| line with the values and approaches of RHEL.
|
| (1): Like docker still not defaulting to rootless even through
| it can. For a hardened context both the the docker user group
| and the ways to run it without the group are security wise a
| no-go in many use-cases. Like docker initially doing way to
| little to make sure non privileged containers are at least
| somewhat sandboxed and taking forever to fix it even when it
| became known it's an issue. Like the way it interacts with
| firewalls and networks rules. Like the way it interacts with
| SELinux. Etc. In companies with dedicated Linux system
| administrators which care about security docker being banned is
| not that rare.
| jrm4 wrote:
| Big picture, it feels like Podman is essential the same way Linux
| used to be.* It doesn't matter if very few people use it -- it's
| presence _prevents_ its much bigger privately-owned brother(s)
| from doing terrible things.
|
| *(I say "used to be" because Linux is now even more essential and
| central, not less.)
| windexh8er wrote:
| > It doesn't matter if very few people use it -- it's presence
| prevents its much bigger privately-owned brother(s) from doing
| terrible things.
|
| I'm going to assume that "bigger privately-owned brother(s)"
| you're referring to Docker? If so, ironic given all of the evil
| things RedHat and IBM do in the OSS realm.
| irusensei wrote:
| Don't take me wrong. Podman is great and I use it instead of
| docker nowadays but when I started using it thinking it was just
| a docker replacement I got burned by UID and GID mappings,
| SELINUX policies, missing DNS configuration and more.
|
| More than once I wrecked my whole setup running system migrate as
| a way to fix problems. It has a whole thing about security ACLs,
| ID mapping and labels. A chmod -R under your home folder will
| probably kill all your containers.
|
| While I'm happy with the results it was far from an "it just
| works" solution like Docker. I imagine things probably have been
| improved since I started using it.
| freedomben wrote:
| 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 they did a good job thinking it through and it has
| yet to interfere with anything else I do. I definitely can't say
| the same for Docker
| zamalek wrote:
| 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.
| xyst wrote:
| 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.
| VoidWhisperer wrote:
| 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.
| tjay1 wrote:
| Same, I tried it on Thursday, I would recommend people on M1
| Macs to stay well clear of podman for now.
| hirako2000 wrote:
| Also worth mentioning that while docker has been catching up by
| offering a rootless mode for years now, it insists on running a
| daemon process.
|
| That daemon is a subtle but incomensurate burden when adopting
| the least privilege principle.
|
| In environments running multiple hosts which themselves run
| multiple containers, typically: k8s, it forces your hand in
| either giving in and grant docker (the daemon) root privilege if
| any one of your container needs root, or to exclude that
| container from running in that environment altogether (since it
| would fail to execute if the docker daemon is in rootless mode).
| Of course the most secure and wise option would be to refractor
| that container and whatever it's doing to run rootlesssly, but
| sometimes this is simply not a reasonable or even possible option
| in order migrate massive complex platform of hundreds of micro
| services with its own history and justified security exceptions.
|
| K8s (and Openshift, which adopts a stronger security by default
| configuration set) provides control over which service accounts
| is granted such exception.
|
| tl-dr: use podman/buildah rather than docker, use openshift
| rather than vanilla k8s.
| throwawaaarrgh wrote:
| Somebody should tell them Docker can run in rootless mode.
| dathinab wrote:
| 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.
| tdiff wrote:
| Could anyone please advise a paper on Docker architecture,
| discussing its design choices (e.g. client-server model) in
| detail?
| tdiff wrote:
| One other thing podman (unlike Docker) is missing is ability to
| run x86 images of Apple silicon under Rosetta. QEMU turns out to
| be too slow for real use.
| oasisaimlessly wrote:
| 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.
| bostik wrote:
| Likely due to technical limitations. At least docker does its
| port-forwarding with iptables (or these days, nftables), and
| the forwarding rules themselves span multiple custom
| tables/chains. If you ever do 'iptables-save' to inspect what
| rules have been created when a container is running, it may
| look a bit funky.
|
| So updating a purportedly single rule might actually require to
| update several underlying traffic mangling rules, with logic
| that is not readily apparent. Or even easy to reason about.
| When you add the ability to route traffic directly from
| container to container without passing through the outermost
| interface, things can get quite hairy.
| coppsilgold wrote:
| I tend to just make and run shell scripts that configure and run
| bubblewrap[1].
|
| Everything is nicely explicit and allows for a good mental model
| of what's going to happen when you run it.
| source "/path/bwrap_helper.sh" FLAGS=(
| ${FLAGS_ROOTFS_DISTROX_MIN[@]} ${FLAGS_ENV_XDG_GUI[@]}
| ${FLAGS_PULSE[@]} ${FLAGS_GPU_ACCEL[@]}
| --new-session --bind /path/jail123 /home/user )
| exec bwrap "${FLAGS[@]}" --seccomp 10 10< /path/a_filter.bpf --
| /usr/bin/gui_app "$@"
|
| [1] <https://github.com/containers/bubblewrap>
___________________________________________________________________
(page generated 2024-01-13 23:00 UTC)