Playground 1 - Client side users
First off, you can play a bit with client-side users, all them in the very same server:
If you want to run containers with a specific uid:gid from the client side (say you trust your users, they are employees and you just want them to avoid interference) you can add the
--user switch after the run. This makes the container to run with those permissions, and when creating files (if there are shared volumes, for example) the user is the one in the host.
For example, say you have in the host the user
alice with 1000:1000 then running the container with
--user 1000 and from the inside you make a
touch /files/hello provided that
/files is mounted, when you exit you will find that the file
hello belongs to alice.
docker run --rm -it --user 2000 ubuntu
If you want to have the user created inside, you can create a Dockerfile FROM a base for example
ubuntu and then create the user inside. I usually add this line in my Dockerfile s:
# Setup the working user "ubuntu"
# TODO: This is host-dependant. We know we want to match user 1000 in the host for everything we do.
addgroup --gid 1000 ubuntu && \
adduser --disabled-password --gecos "" --uid 1000 --ingroup ubuntu ubuntu && \
Then you can run the
--user switch with the username (in this case the user
ubuntu) instead of the number. Suppose my image is named
myubuntu then I could do:
docker run --rm -it --user ubuntu myubuntu
This will run
myubuntu with user 1000.
All this will not solve your problem. Users still be able to see the other’s processes… but will help to get familiar with options in the docker.
Playground 2 - multiple daemons in the same server
Once you are familiar with client-side users, maybe you can try to run multiple docker daemons. In that case, you need to take care that the daemons do not “overwrite” the other’s files.
For example: Where are the images stores? Where are the layers for the running containers? etc.
In this stack-overflow question https://stackoverflow.com/questions/32334167/is-it-possible-to-start-multiple-docker-daemons-on-the-same-machine/34058675 benizi lists a set of “conflicting options” that you’ll have to set different for each daemon.
Not only the location at which the working files are stored, but also operational files like where’s the PID stored.
Also, as benizi states, you’ll have to give the different daemons different “sockets” to listen to. In this, the
--host switch plays a role.
If you look at the example script, he sets it via a parameter in
Then, your client will have to tell “what daemon to connect to”, for example specifying the
-H option like in this client command:
docker -H unix://$HOME/altdocker.socket run --rm -i -t alpine sh
Additionally to this you can look at https://docs.docker.com/engine/reference/commandline/dockerd/ for the million options you have there to play with to “fine-tune” each of the daemons.
Probably the option
--userns-remap can help. From the documentation:
--userns-remap string User/Group setting for user namespaces
And later in the same document, quote:
The Linux kernel user namespace support provides additional security by enabling a process, and therefore a container, to have a unique range of user and group IDs which are outside the traditional user and group range utilized by the host system. Potentially the most important security improvement is that, by default, container processes running as the
root user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged
uid on the host.
This finally takes you to https://docs.docker.com/engine/security/userns-remap/ entitled
Isolate containers with a user namespace
There’s a lot to digest… take it easy!
Still, think that this will not protect against a user doing
ps -xauf and watching all the processes in the host, even administrative processes owned by root your yourself, or other admin non-privileged users.
This makes me think… what’s exactly your use-case? Why do you want that “alice” can’t see the docker processess of “bob”, when alice all the time has been able to see bob’s processes in a bash? Are they teammates? Customers sharing a machine? Are they people that don’t trust each other? It’s just a lab-experiment? Is it a real use case?
The context probably can help think laterally. Maybe there’s a less-overkill solution to your problem.
Hope to help!