Discussion
Yet another reason to _always_ isolate your containers in VMs on a locked down bridge. Side-by-siding containers directly on the host with 'rootless' is not true isolation. Docker networks can also be a hot mess, and the given project's own firewalling can scribble/overstep that of host firewall.
If lacking the knowledge to isolate properly, just stick with one Docker project per VPS.
Thanks @themadhatter for the heads-up on this one. Woke up to it.
@benjaoming @themadhatter They gamble tbh with the suite of containers strategy but at least each are under their gaze. The de-privileging they do in the AIO containers is pretty good, but will need to be audited in light of this to confirm if musl is in any of the containers (incl optional) the master pulls in. Redis could be a worry. I've not looked at ClamAV
They have a good security team, we'll soon know. Unrelated: I wish they would finally set a sane de facto umask for NC data directory!
@JulianOliver What's your preferred VM setup for this?
@mez For smaller VM pools I tend to use native Qemu/KVM, host passthrough mode, each guest on a local bridge network, reached over SSH with host-local pubkey auth, shell scripts for management. Locked down Debian GNU/Linux host. FreeBSD with bhyve is really nice too.
@mez When handing a VM to an org to manage themselves, I put it on the VPN, hand out the conf, and they tunnel right in without touching the host (not a fan of multi-user systems).
@mez FWIW this is covered in the Fortress training https://courses.nikau.io/fortress
@JulianOliver @themadhatter Is Nextcloud's All-In-One Docker architecture something to be skeptical of?
```
sudo docker run \
(...)
--volume /var/run/docker.sock:/var/run/docker.sock:ro \
ghcr.io/nextcloud-releases/all-in-one:latest
```
❓