Réponses:
docker.sock
est le socket UNIX que le démon Docker écoute. C'est le principal point d'entrée de l'API Docker. Il peut également s'agir d'un socket TCP, mais par défaut, pour des raisons de sécurité, Docker utilise par défaut le socket UNIX.
Le client cli Docker utilise ce socket pour exécuter les commandes docker par défaut. Vous pouvez également remplacer ces paramètres.
Il peut y avoir différentes raisons pour lesquelles vous devrez peut-être monter le socket Docker à l'intérieur d'un conteneur. Comme lancer de nouveaux conteneurs depuis un autre conteneur. Ou à des fins de découverte de service automatique et de journalisation. Cela augmente la surface d'attaque, vous devez donc faire attention si vous montez le socket docker à l'intérieur d'un conteneur, des codes de confiance s'exécutent à l'intérieur de ce conteneur, sinon vous pouvez simplement compromettre votre hôte qui exécute le démon docker, car Docker par défaut lance tous les conteneurs en tant que root.
Docker socket a un groupe docker dans la plupart des installations afin que les utilisateurs de ce groupe puissent exécuter des commandes docker sur le socket docker sans autorisation root, mais les conteneurs docker réels obtiennent toujours l'autorisation root car le démon docker s'exécute efficacement en tant que root (il a besoin d'une autorisation root pour accéder à l'espace de noms et aux groupes de contrôle) .
J'espère que cela répond à votre question.
Plus d'infos: https://docs.docker.com/engine/reference/commandline/dockerd/#examples
/var/run/docker.sock
à l'intérieur du conteneur est une pratique courante, mais très dangereuse. Un attaquant peut exécuter n'importe quelle commande que le service docker peut exécuter, ce qui donne généralement accès à tout le système hôte lorsque le service docker s'exécute en tant que root. "
Je sais qu'il est un peu tard mais j'espère que ma réponse vous donnera tant d'idées
Permettez-moi d'abord de parler des sockets Unix
Le terme sockets fait généralement référence aux sockets IP. Ce sont ceux qui sont liés à un port (et à une adresse), auxquels nous envoyons des requêtes TCP et dont nous obtenons des réponses.
Un autre type de socket est un socket Unix, ces sockets sont utilisés pour IPC (Interprocess Communication). Ils sont également appelés sockets de domaine Unix ( UDS ). Les sockets Unix utilisent le système de fichiers local pour la communication, tandis que les sockets IP utilisent le réseau.
Le démon Docker peut écouter les requêtes API Docker Engine via trois différents types de Socket: unix, tcp, and fd
.
Par défaut, un socket de domaine Unix (ou socket IPC) est créé dans /var/run/docker.sock
Voyons quelques exemples en direct :
Docker Server utilise ce socket pour écouter l'API REST et les clients utilisent le socket pour envoyer des demandes d'API au serveur.
curl peut parler à un socket Unix via le
--unix-socket
drapeau. Étant donné que l'API Docker Server est exposée en tant que REST, nous aurions besoin d'envoyer des commandes via HTTP. De plus, comme ce serveur est local (rappelez-vous, le système de fichiers), nous pouvons passer n'importe quel nom d'hôte dans l'URL (ou nous en tenir à l'hôte local, cela fonctionnera bien aussi!). Le serveur ne se soucie pas du nom d'hôte, juste du chemin.
curl --unix-socket /var/run/docker.sock http://localhost/images/json | jq
[
{
"Containers": -1,
"Created": 1525888860,
"Id": "sha256:24a77bfbb9ee3aeef9e24766ad6e9fa57f85c67596f154e8916e4f314067e149",
"Labels": null,
"ParentId": "",
"RepoDigests": [
"postgres@sha256:b06cdddba62f1550a1c674270814e72eaa8734d95912019b4ddc288b650ad67d"
],
"RepoTags": null,
"SharedSize": -1,
"Size": 39507096,
"VirtualSize": 39507096
}
]
Quelques commandes :
Vous pouvez faire beaucoup de choses avec docker.sock
consultez ce bel article