Considering how many apps use docker nowadays, that really surprises me that they wouldn’t support it. There’s that linuxserver docker repository that’s packaged hundreds of applications for docker.
Yunohost is focused on easy install on among others a VPS. If the VPS provider runs OpenVZ or LXC in their infrastructure then Docker is either not possible, or with limitations or first needs tweaking by the provider.
Docker is not bad for security, unless you do insecure things like exposing your Docker socket or running random workloads as root, however those are just as insecure under systemd.
This is not insecure. It is surprising if you don’t know how containers work, but in a real deployment you’d only bind to localhost and use a reverse proxy and that is perfectly safe.
As I said this is surprising if you don’t know how containers work. This is similar from how e.g. virtual machine networking would trip you. As long as you know how to set things up properly, which is documented at length, Docker is not “insecure”.
You are saying that if one installs containers or VMs with Qemu or VirtualBox or OpenVZ or LXC or Kubernetes or VMware these technologies will all punch holes to the outside by default despite the iptables setup of the host machine ?
So-called “bridged networking” is not the default for VirtualBox but it is recommended for Qemu, yes. In that case only the routing rules on the bridge apply, not the filtering rules on your host’s interface.
How is this different from say, SystemD? It runs as root and has a larger attack surface.
The link you pointed out has every CVE for every application packaged as Docker image. Would you make the same point that APT or AppImage is insecure because there are insecure applications packaged that way?
It’s very different because SystemD does way more things than running containers.
Also, this is whataboutism.
The link you pointed out has every CVE for every application packaged as Docker image.
You could scan through the list and check for yourself which ones are due to docker itself.
Besides, I updated the link to filter out the spurious CVEs.
Would you make the same point that APT or AppImage is insecure because there are insecure applications packaged that way?
I would not… unless the tool itself was actively encouraging bad security practices, for example bundling dependencies, as Docker/AppImage/Flatpak/Snap do.
It is not whataboutism since SystemD is what you’ll use to run services if you don’t use Docker… If I say that mass transit is a terrible idea because it pollutes, and you point out that cars pollute even more, I can’t claim “whataboutism” to dismiss your argument.
Considering how many apps use docker nowadays, that really surprises me that they wouldn’t support it. There’s that linuxserver docker repository that’s packaged hundreds of applications for docker.
Yunohost is focused on easy install on among others a VPS. If the VPS provider runs OpenVZ or LXC in their infrastructure then Docker is either not possible, or with limitations or first needs tweaking by the provider.
deleted by creator
docker is really bad for security and adds a lot of unnecessary complexity
Docker is not bad for security, unless you do insecure things like exposing your Docker socket or running random workloads as root, however those are just as insecure under systemd.
It has some weird behaviour, for example ufw rules dont apply to Docker.
This is not insecure. It is surprising if you don’t know how containers work, but in a real deployment you’d only bind to localhost and use a reverse proxy and that is perfectly safe.
Not insecure ? Here an old blog post about it https://blog.viktorpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html btw, Docker also had/has Google DNS as fallback, so the moment your DNS servers fail to respond Docker uses Google, not very privacy friendly.
As I said this is surprising if you don’t know how containers work. This is similar from how e.g. virtual machine networking would trip you. As long as you know how to set things up properly, which is documented at length, Docker is not “insecure”.
You are saying that if one installs containers or VMs with Qemu or VirtualBox or OpenVZ or LXC or Kubernetes or VMware these technologies will all punch holes to the outside by default despite the iptables setup of the host machine ?
So-called “bridged networking” is not the default for VirtualBox but it is recommended for Qemu, yes. In that case only the routing rules on the bridge apply, not the filtering rules on your host’s interface.
Docker runs the whole daemon as root and has a large attack surface. Also, it has a lot of footguns that can mislead the user. Its security track record speaks for itself: https://www.cvedetails.com/product/28125/Docker-Docker.html?vendor_id=13534
How is this different from say, SystemD? It runs as root and has a larger attack surface.
The link you pointed out has every CVE for every application packaged as Docker image. Would you make the same point that APT or AppImage is insecure because there are insecure applications packaged that way?
It’s very different because SystemD does way more things than running containers. Also, this is whataboutism.
You could scan through the list and check for yourself which ones are due to docker itself. Besides, I updated the link to filter out the spurious CVEs.
I would not… unless the tool itself was actively encouraging bad security practices, for example bundling dependencies, as Docker/AppImage/Flatpak/Snap do.
It is not whataboutism since SystemD is what you’ll use to run services if you don’t use Docker… If I say that mass transit is a terrible idea because it pollutes, and you point out that cars pollute even more, I can’t claim “whataboutism” to dismiss your argument.
Here’s the corresponding page for SystemD: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 as you can see there are even more vulnerabilities, which makes sense as the attack surface is even larger.