Share and learn in the Docker community.
Hi Everyone,
I am new to docker I am having trouble with hiding the docker container.
I launched docker container using nginx from xyz user.
When I list docker containers from other user like abc user it is showing the container which was launched by xyz container.
My requirement is when I do docker ps from abc user it should not show containers which are launched by xyz user.
I want to launch containers in user specific.
Can you please guide me how to achieve it.
Thanks in advance.
I’m also rather new to docker internals, but I guess you should run a specific docker daemon for each user, maybe running with specific uid:gid for isolation, then let their clients to connect to their specific daemon.
By default docker does not “hide” the processes; the same way an unprivileged user in a classical linux box can do ps -xauf and see all the processes of all users and who is owning the process.
Thank you for your reply.
Can you please let me know the steps to run containers using uid:gid.
Thank in advance…
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.
Try this:
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.
RUN \
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.
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 Is it possible to start multiple docker daemons on the same machine - Stack Overflow 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 --host=unix://$base.socket.
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 dockerd | Docker Docs 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
rootuser will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivilegeduidon the host.
This finally takes you to Isolate containers with a user namespace | Docker Docs 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!
I would recommend running a Docker per user, by running Docker (CLI + daemon) inside a container.
This used to require privileged containers, but check out Sysbox, a new type of “runc” that allows you to do this easily and with rootless containers (user-namespace). It’s as simple as:
docker run --runtime=sysbox-runc -it nestybox/ubuntu-bionic-systemd-docker
The docker inside that container is fully isolated from the underlying host, so you can spawn multiple such containers for your users and give them ssh access. The users can ssh into the container and will have their own Docker each. The containers created by the (inner) docker will live inside the outer container. This blog article has more on this.
Hope this helps!