3 ms·

Docker compose is what we are going with (for now), but with one complication: how can I allow co-workers access without giving them root access to the server?

Docker compose is what we are going with (for now), but with one complication: how can I allow co-workers access without giving them root access to the server? I generally trust them (we're a tight knit group), but mistakes happen. Now I could (and did) add them to the 'docker' group so they can run docker(-compose), but the issue ends up being permissions on any bind mounts. They end up not being able to read logs, view some config, etc. It's not necessarily a single-server monolith, but a server that is meant to handle a multitude of (possibly unrelated) web-apps at once. I might have to think about VMs more. I really do like docker, and traefik is a god-send (making routing and certificates a heck of a lot easier).

sh34r 3y ago
Security is generally considerably more challenging with containers than VMs. https://docs.docker.com/engine/security/#docker-daemon-attack-surface https://docs.docker.com/engine/security/#docker-daemon-attac... "Running containers (and applications) with Docker implies running the Docker daemon. This daemon requires root privileges unless you opt-in to Rootless mode..." If they can log into the server and run docker containers themselves, you've probably inadvertently granted permissions that could be escalated to gain root access, if they were a sufficiently skilled adversary (or their user account is compromised by one). You typically avoid this particular problem by having a CI/CD pipeline build, deploy, and run the containers. No one has permission to do this except the pipeline. Grant devs ssh access to the containers, using appropriate network rules to limit access to trusted IPs, and ideally behind a jump box in a VPC. VMs give you a lot of OS-level protections for free. For one thing, getting root access to a VM shouldn't compromise the host or other VMs (in the absence of a 0-day, anyway). Unfortunately, it sounds like you're pretty far down the Docker rabbit hole already. It's probably much more trouble to switch now than it's worth.

sh34r 3y ago

Security is generally considerably more challenging with containers than VMs. https://docs.docker.com/engine/security/#docker-daemon-attack-surface https://docs.docker.com/engine/security/#docker-daemon-attac... "Running containers (and applications) with Docker implies running the Docker daemon. This daemon requires root privileges unless you opt-in to Rootless mode..." If they can log into the server and run docker containers themselves, you've probably inadvertently granted permissions that could be escalated to gain root access, if they were a sufficiently skilled adversary (or their user account is compromised by one). You typically avoid this particular problem by having a CI/CD pipeline build, deploy, and run the containers. No one has permission to do this except the pipeline. Grant devs ssh access to the containers, using appropriate network rules to limit access to trusted IPs, and ideally behind a jump box in a VPC. VMs give you a lot of OS-level protections for free. For one thing, getting root access to a VM shouldn't compromise the host or other VMs (in the absence of a 0-day, anyway). Unfortunately, it sounds like you're pretty far down the Docker rabbit hole already. It's probably much more trouble to switch now than it's worth.