Docker socket

Fiche express
Type	Exposition de l'API Docker (socket local ou TCP distant)
Socket par défaut	unix:///var/run/docker.sock
Port TCP usuel (TLS)	2376
Port TCP usuel (sans TLS)	2375 — à réserver au réseau local de confiance
Voir aussi	Docker daemon.json · Docker pratiques · TLS · Systemd

Par défaut, le démon Docker n'écoute que sur le socket UNIX local /var/run/docker.sock : seuls les utilisateurs locaux membres du groupe docker (ou root) peuvent piloter l'API. Exposer cette API sur le réseau (client distant, intégration CI/CD, outillage centralisé) nécessite une configuration explicite, et cette configuration doit être protégée par TLS mutuel : un accès Docker en clair équivaut à donner un accès root sur l'hôte à quiconque peut atteindre le port.

Documentation officielle

• https://docs.docker.com/engine/security/https/
• https://docs.docker.com/engine/security/protect-access/

Mise en place d'un accès distant sécurisé (TLS mutuel)

Génération des certificats côté serveur

Autorité de certification locale, puis certificat serveur :

openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem \
  -subj "/C=FR/ST=IDF/L=Paris/O=Example/OU=IT/CN=$HOSTNAME"

openssl genrsa -out server-key.pem 4096
openssl req -subj "/CN=$HOSTNAME" -sha256 -new -key server-key.pem -out server.csr

echo subjectAltName = DNS:$HOSTNAME,IP:<IP privée du serveur>,IP:127.0.0.1 >> extfile.cnf
echo extendedKeyUsage = serverAuth >> extfile.cnf

openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem -extfile extfile.cnf

Génération du certificat client

openssl genrsa -out key.pem 4096
openssl req -subj '/CN=client' -new -key key.pem -out client.csr
echo extendedKeyUsage = clientAuth > extfile-client.cnf

openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out cert.pem -extfile extfile-client.cnf

Permissions sur les certificats

Les clés privées doivent rester lisibles uniquement par leur propriétaire :

chmod -v 0400 ca-key.pem key.pem server-key.pem
chmod -v 0444 ca.pem server-cert.pem cert.pem

Activation du mode tlsverify côté démon

Dans /etc/docker/daemon.json :

{
  "tlsverify": true,
  "tlscacert": "/etc/docker/certs/ca.pem",
  "tlscert": "/etc/docker/certs/server-cert.pem",
  "tlskey": "/etc/docker/certs/server-key.pem"
}

Puis, dans l'unit systemd du service (/lib/systemd/system/docker.service), adapter la ligne ExecStart pour faire écouter le démon sur l'interface réseau souhaitée :

ExecStart=/usr/bin/dockerd -H 0.0.0.0:2376 --containerd=/run/containerd/containerd.sock

systemctl daemon-reload
systemctl restart docker

Écouter sur 0.0.0.0 avec tlsverify actif reste risqué si aucun pare-feu ne restreint l'accès au port 2376 : à limiter au réseau d'administration.

Configuration du client

Copier l'autorité et le certificat client sur la machine cliente, puis positionner les variables d'environnement du client Docker :

mkdir -pv ~/.docker
cp -v {ca,cert,key}.pem ~/.docker

export DOCKER_HOST=tcp://<IP privée du serveur Docker>:2376
export DOCKER_TLS_VERIFY=1

Test de connexion :

docker version

Alternative : socket TCP sans TLS

Pour un usage strictement local ou en environnement de test isolé, il est possible d'exposer un second listener TCP sans authentification, en plus du socket UNIX — voir la section correspondante de Docker pratiques. Cette configuration ne doit jamais être exposée au-delà d'un réseau de confiance : elle donne un accès équivalent à root sur l'hôte, sans authentification ni chiffrement.