First of all, only trusted users should be allowed to control your Docker daemon
The docker daemon runs as root by default on a Debian Bullseye installation. Adding a user to the
docker group gives that user psuedo root access due to having control of the docker daemon having that amount of access. Every user in the docker group will have complete control of the host and others containers and can run a container that
--publishes any port.
There are a few options to providing security to users docker access.
- Rootless docker
1. Rootless docker
A rootless docker setup would enable each user to run a docker deamon. For ports lower than 1024 it would need to abide by the unprivileged ports information bob provided as each user will "own" their own deamon. Docker also provides related guidance. This wouldn't stop Anna from taking Bobs port.
The simplest method to allow users to run docker commands is to provide a root controlled script via sudo that is either static, or controls the user input for optional arguments:
docker run --detach --publish 1300:1300 anna/app-image
anna ALL=(root) NOPASSWD: /usr/local/bin/start-anna-image
If you want users to be able to add their own options you need to be very careful about controlling their input as it's vert easy to
3. Authorization plugin or API for Docker
As Docker doesn't provide any authorization layer on the daemon you need to add something to control user access.
Docker provides an in built authorization plugin framework to enable this. Some examples are opa-docker-authz and casbin-authz-plugin
You could give the users access to a form of proxy API that provides the authentication and authorization over what is passed on to the Docker REST API. There are docker libraries for most programming languages. Kubernetes+RBAC is an example of an API that sits in front of the Docker daemon and controls access (just a very big/complex one that does a lot more).
docker run -v /:/pwn -it cyclic3/pwnto get complete r/w access to the entire filesystem, and adding the
--privilegedis almost functionally identical from being root on that machine. I have seen this go wrong so many times, including in a CTF run by a large cyber company where it was intentional for a single challenge, but ended up exposing all the machines used for that category. It can be done securely, but I think it's really important to stress just how far south this can go.