I want to add Authentication and Authorization for the docker daemon for more security.
use case :-
Any command can be issued to the docker daemon by only valid user and that the user has the rights to execute the command. Here I want to use LDAP for user authentication.
Q :- Does docker has integration with LDAP for above use case ? If not then any work around to do this ?
I want help how to proceed on this. some starters will help.
Please advise me. Thanks for answer !
One way to protect docker daemon is to give access to the socket file only to users who should have access. Docker uses a group called docker, so adding a user to this group gives access to all docker commands gpasswd -a user docker. This however does not restrict the commands a user can run.
If you'd prefer LDAP authentication and restriction on commands, take a look at Docker remote API which is used internally by docker client as well. You can use it to control docker daemon, add your own authentication, restriction on commands, etc.
Related
Recently, I began to use docker for my lab's server. The server is a Linux server with Ubuntu server 18.04 installed. Users' login authentication is using Windows Active Directory (AD). My current solution to run non-root docker is by adding users to docker group (ref).
However, I found a severe security problem. AD user A can run docker container as any other user B by docker run -u B's uid:B's gid. In the container, A can get all B's permission.
The proper way to run non-root docker may be the newly introduced 'Rootless mode', The problem is that rootless mode need newuidmap and newgidmap, but AD users are not listed in /etc/passwd and /etc/subuid etc, which means rootless mode and as well as userns-remap mode cannot be used for my situation (i.e. AD auth).
Is there any method to tackle this issue? Thanks so much.
Best.
We're using docker for our project. We've a monitoring service (for our native application) which is running on Docker.
Currently there is no user management for this monitoring service. Is there any way we can add user management from Dockerfile?
Please note that I'm not looking docker container user management.
In simple words functionality that I'm looking for is:
Add any user and password in dockerfile.
While accessing external IP, same user and password must be provided to view running monitoring service.
From your few information about your setup, I would say the authentification should be handled by your monitoring service. If this was a kind of webapp you could use a simple basic auth as a first step.
Docker doesn't know what's running in your container, and its networking setup is limited to a simple pass-through between containers or from host ports to containers. It's typical to run programs with many different network protocols in Docker (Web servers, MySQL, PostgreSQL, and Redis all have different wire protocols) and there's no way Docker on its own could inject an authorization step.
Many non-trivial Docker setups include some sort of HTTP reverse proxy container (frequently Nginx, occasionally Apache) that can both serve a Javascript UI's built static files and also route HTTP requests to a backend service. You can add an authentication control there. The mechanics of doing this would be specific to your choice of proxy server.
Consider that any information you include in the Dockerfile or docker build --args options can be easily retrieved by anyone who has your image (looking at its docker history, or docker run a debug shell on it). You may need to inject the credentials at run time using a bind mount if you think they're sensitive and you're not storing your image somewhere with strong protections (if anyone can docker pull it from Docker Hub).
Am I understanding correctly that the docs discuss how to protect the Docker daemon when commands are issued (docker run,...) with a remote machine as the target? When controlling docker locally this does not concern me.
Running Docker swarm does not require this step either as the security between the nodes is handled by Docker automatically. For example, using Portainer in a swarm with multiple agents does not require extra security steps due to overlay network in a swarm being encrypted by default.
Basically, when my target machine will always be localhost there are no extra security steps to be taken, correct?
Remember that anyone who can run any Docker command can almost trivially get unrestricted root-level access on the host:
docker run -v/:/host busybox sh
# vi /host/etc/passwd
So yes, if you're using a remote Docker daemon, you must run through every step in that document, correctly, or your system will get rooted.
If you're using a local Docker daemon and you haven't enabled the extremely dangerous -H option, then security is entirely controlled by Unix permissions on the /var/run/docker.sock special file. It's common for that socket to be owned by a docker group, and to add local users to that group; again, anyone who can run docker ps can also trivially edit the host's /etc/sudoers file and grant themselves whatever permissions they want.
So: accessing docker.sock implies trust with unrestricted root on the host. If you're passing the socket into a Docker container that you're trusting to launch other containers, you're implicitly also trusting it to not mount system directories off the host when it does. If you're trying to launch containers in response to network requests, you need to be insanely careful about argument handling lest a shell-injection attack compromise your system; you are almost always better off finding some other way to run your workload.
In short, just running Docker isn't a free pass on security concerns. A lot of common practices, if convenient, are actually quite insecure. A quick Web search for "Docker cryptojacking" can very quickly find you the consequences.
Working on the latest graphite/grafana docker container which is a linux base and would like to have it use ldap to reach out to AD for user auth.
I was able to SSH to the container and install openldap then make a successfully query to AD.
I was able to configure the port forwarding for ldap from the instance to the container. However authentication is failing with a protocol error back to the container.
Does anyone have any concrete steps for setting this up please? Appreciated.
I have created a docker container from ubuntu image. Other users can attach to this container by docker exec -it CONTAINER_ID bash. Is there a way to add username and password for this command? I don't want my container to be accessed by other users. I want when users execute docker exec command to attach to my container, it prompts to ask a username and password. Users can only attach to it after input a correct username and password. Just like what ssh does.
Access to the docker socket (which is used by the docker command line), should be treated as sysadmin level access to the host and all containers being run on that host.
You can configure the docker daemon to listen on a port with TLS credentials and validation of client certificates. However, once a user has access to any docker API calls, they would have access to them all, and without any login prompts.
You could try a third party plugin provided by Twistlock that implements the authz plugin for docker. This will let you limit access to the exec call to specific TLS client certificates. However it will not limit which containers they can exec into.
Probably the closest to what you want comes with Docker's EE offering, specifically UCP. It's a commercial tool, but they provide a different API entrypoint that performs its own authentication, including the option for a user/password with web based requests, and RBAC security that lets you limit access to calls like exec to specific users and specific collections of containers.
If you wanted to do this from the container side, I'm afraid that won't work. Exec is run as a Linux exec syscall directly inside the container namespace, so there's nothing inside the container you could do to prevent that sort of access. The best option is to remove any commands from your image that you don't want anyone to be able to run in the container.