Sur les pages de documentation de Docker, toutes les commandes d'exemple sont présentées sans sudo
, comme celle-ci :
docker ps
Sur Ubuntu, le binaire s'appelle docker.io
. Il ne fonctionne pas non plus sans sudo :
sudo docker.io ps
Comment puis-je configurer Docker pour ne pas avoir à préfixer chaque commande Docker par sudo ?
Bonne nouvelle : le nouveau docker (version 19.03 (actuellement expérimentale)) sera capable de fonctionner sans racine, annulant ainsi les problèmes qui peuvent survenir en utilisant un utilisateur root. Plus besoin de s'embrouiller avec des permissions élevées, root et tout ce qui pourrait ouvrir votre machine quand vous ne le voulez pas.
Video about this from [[DockerCon 2019] Hardening Docker daemon with Rootless mode][1]
Quelques mises en garde concernant le mode Docker sans racine.
Les ingénieurs de Docker affirment que le mode sans racine ne peut pas être considéré comme un remplacement de la suite complète des fonctionnalités du moteur Docker. Voici quelques limitations au mode sans racine :
- Les contrôles de ressources cgroups, les profils de sécurité apparmor, les points de contrôle/restauration, les réseaux superposés, etc. ne fonctionnent pas en mode sans racine.
- L'exposition des ports à partir des conteneurs nécessite actuellement un processus manuel d'assistance socat.
- Seuls les distros basés sur Ubuntu supportent les systèmes de fichiers superposés en mode sans racine.
- Le mode sans racine n'est actuellement fourni que pour les nightly builds qui peuvent ne pas être aussi stables que ceux auxquels vous êtes habitués.
Depuis la version 19.3 de Docker, ce mode est obsolète (et plus dangereux que nécessaire) :
Le [manuel de docker][2] a ceci à dire à ce sujet :
Donner un accès non-root
Le démon docker s'exécute toujours sous l'utilisateur root et, depuis la version 0.5.2 de Docker, le démon docker se lie à un socket Unix au lieu d'un port TCP. Par défaut, ce socket Unix appartient à l'utilisateur root, et donc, par défaut, vous pouvez y accéder avec sudo.
À partir de la version 0.5.3, si vous (ou votre installateur Docker) créez un groupe Unix appelé docker et y ajoutez des utilisateurs, le démon docker rendra la propriété du socket Unix accessible en lecture/écriture par le groupe docker au démarrage du démon. Le démon docker doit toujours être exécuté en tant qu'utilisateur root, mais si vous exécutez le client docker en tant qu'utilisateur du groupe docker, vous n'avez pas besoin d'ajouter sudo à toutes les commandes du client. Depuis la version 0.9.0, vous pouvez spécifier qu'un groupe autre que docker doit posséder le socket Unix avec l'option -G.
Attention : Le groupe docker (ou le groupe spécifié avec -G) est équivalent à root ; voir [Docker Daemon Attack Surface details][3] et ce blogpost sur [Why we don't let non-root users run Docker in CentOS, Fedora, or RHEL ][4] (merci michael-n).
Dans la récente version du [mode sans racine expérimental sur GitHub][5], les ingénieurs mentionnent que le mode sans racine permet d'exécuter dockerd en tant qu'utilisateur non privilégié, en utilisant user_namespaces(7), mount_namespaces(7), network_namespaces(7).
Les utilisateurs doivent exécuter dockerd-rootless.sh à la place de dockerd.
$ dockerd-rootless.sh --experimental
Comme le mode Rootless est expérimental, les utilisateurs doivent toujours exécuter dockerd-rootless.sh avec -experimental.
Important à lire : [étapes de post-installation pour Linux][6] (il existe également un lien vers [Docker Daemon Attack Surface details][3]).
**Gérer Docker en tant qu'utilisateur non root***.
Le démon Docker se lie à un socket Unix au lieu d'un port TCP. Par défaut, ce socket Unix appartient à l'utilisateur root et les autres utilisateurs ne peuvent y accéder qu'en utilisant sudo. Le démon Docker s'exécute toujours en tant qu'utilisateur root.
Si vous ne souhaitez pas utiliser sudo lorsque vous utilisez la commande docker, créez un groupe Unix appelé docker et ajoutez-y des utilisateurs. Lorsque le démon docker démarre, il rend la propriété de la socket Unix lisible/inscriptible par le groupe docker.
Ajoutez le groupe docker s'il n'existe pas déjà :
sudo groupadd docker
Ajoutez l'utilisateur connecté "$USER" au groupe docker. Changez le nom d'utilisateur pour qu'il corresponde à votre utilisateur préféré si vous ne voulez pas utiliser votre utilisateur actuel :
sudo gpasswd -a $USER docker
Faites un newgrp docker
ou déconnectez-vous pour activer les changements de groupes.
Vous pouvez utiliser
docker run hello-world
pour vérifier si vous pouvez exécuter docker sans sudo.
[1] : https://www.slideshare.net/AkihiroSuda/dockercon-2019-hardening-docker-daemon-with-rootless-mode [2] : https://docs.docker.com/engine/installation/linux/ubuntulinux/#/create-a-docker-group [3] : https://docs.docker.com/engine/security/security/#/docker-daemon-attack-surface [4] : https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/ [5] : https://github.com/moby/moby/blob/master/docs/rootless.md [6] : https://docs.docker.com/engine/installation/linux/linux-postinstall/
Pour exécuter la commande docker sans sudo
, vous devez ajouter votre utilisateur (qui a les privilèges de root) au groupe docker. Pour cela, exécutez la commande suivante :
sudo usermod -aG docker $USER
Maintenant, faites en sorte que l'utilisateur se déconnecte puis se reconnecte. Cette solution est bien expliquée [ici][1] avec une installation correcte.
[1] : http://jee-appy.blogspot.com/2016/02/installing-docker-in-virtual-box.html
Le mécanisme par lequel l'ajout d'un utilisateur au groupe docker
accorde la permission d'exécuter docker est d'obtenir l'accès au socket de docker à /var/run/docker.sock
. Si le système de fichiers qui contient /var/run
a été monté avec les ACLs activées, ceci peut également être réalisé via les ACLs.
sudo setfacl -m user:$USER:rw /var/run/docker.sock
Je n'inclus ceci que par souci d'exhaustivité.
En général, je recommande d'éviter les ACL lorsqu'une bonne alternative basée sur les groupes est disponible : Il est préférable que les privilèges dans un système puissent être compris en regardant uniquement les appartenances aux groupes. Il est préférable de pouvoir comprendre les privilèges d'un système en examinant uniquement l'appartenance à un groupe. Le fait de devoir rechercher les entrées ACL dans le système de fichiers afin de comprendre les privilèges du système constitue une charge supplémentaire pour les audits de sécurité.
Avertissement 1 : Ceci a la même équivalence root
que d'ajouter username
au groupe docker
. Vous pouvez toujours démarrer un conteneur d'une manière qui a un accès root
au système de fichiers de l'hôte.
Avertissement 2 : Les ACLs sont significativement plus difficiles pour les audits de sécurité que la sécurité basée sur les groupes. Evitez probablement les ACLs si possible lorsque vous pouvez utiliser des groupes à la place, au moins dans les environnements sensibles aux audits.