Installing Docker on Your System with the Universal Installation Script.Probably avoid ACLs if possible when you can use groups instead, at least in audit-relevant environments. Warning 2: ACLs are significantly more difficult for security audits than group-based security. You can still start a container in a way that has root access to the host filesystem. Warning 1: This has the same root equivalence as adding $USER to the docker group. Having to scan the file system for ACL entries in order to understand system privileges is an additional burden for security audits. In general, I recommend to avoid ACLs whenever a good alternative based on groups is available: It is better if the privileges in a system can be understood by looking at group memberships only. I'm only including this for completeness. sudo setfacl -m user:$USER:rw /var/run/docker.sock If the filesystem that contains /var/run has been mounted with ACLs enabled, this can also be achieved via ACLs. The mechanism by which adding a user to group docker grants permission to run docker is to get access to the socket of docker at /var/run/docker.sock. To check if you can run Docker without sudo. Change the user name to match your preferred user if you do not want to use your current user: sudo gpasswd -a $USER dockerĮither do a newgrp docker or log out/in to activate the changes to groups. When the docker daemon starts, it makes the ownership of the Unix socket read/writable by the docker group.Īdd the docker group if it doesn't already exist: sudo groupadd dockerĪdd the connected user "$USER" to the docker group. If you don’t want to use sudo when you use the docker command, create a Unix group called docker and add users to it. The docker daemon always runs as the root user. By default that Unix socket is owned by the user root and other users can only access it using sudo. The docker daemon binds to a Unix socket instead of a TCP port. Important to read: post-installation steps for Linux (it also links to Docker Daemon Attack Surface details). $ dockerd-rootless.sh -experimentalĪs Rootless mode is experimental, users need to always run dockerd-rootless.sh with –experimental. Users need to run dockerd-rootless.sh instead of dockerd. In the recent release of the experimental rootless mode on GitHub, engineers mention rootless mode allows running dockerd as an unprivileged user, using user_namespaces(7), mount_namespaces(7), network_namespaces(7). Warning: The docker group (or the group specified with -G) is root-equivalent see Docker Daemon Attack Surface details and this blogpost on Why we don't let non-root users run Docker in CentOS, Fedora, or RHEL (thanks michael-n).
As of 0.9.0, you can specify that a group other than docker should own the Unix socket with the -G option. The docker daemon must always run as the root user, but if you run the docker client as a user in the docker group then you don't need to add sudo to all the client commands. Starting in version 0.5.3, if you (or your Docker installer) create a Unix group called docker and add users to it, then the docker daemon will make the ownership of the Unix socket read/writable by the docker group when the daemon starts. By default that Unix socket is owned by the user root, and so, by default, you can access it with sudo. The docker daemon always runs as the root user, and since Docker version 0.5.2, the docker daemon binds to a Unix socket instead of a TCP port.
DOCKER SUDO NOT FOUND MANUAL
The Docker manual has this to say about it:
Video about this from Hardening Docker daemon with Rootless modeĪ few Caveats to the rootless Docker modeĭocker engineers say the rootless mode cannot be considered a replacement for the complete suite of Docker engine features. No more messing with elevated permissions, root, and anything that might open up your machine when you did not want to.
Good news: the new Docker version 19.03 (currently experimental) will be able to run rootless negating the problems that can occur using a root user.
0 kommentar(er)
