Docker Community Forums

Share and learn in the Docker community.

Hide docker container

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…

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.

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.
    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 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 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 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!