technique:docker:admin:socket-certs

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
technique:docker:admin:socket-certs [2020/10/14 15:53] – qduchemitechnique:docker:admin:socket-certs [2022/09/23 10:00] (Version actuelle) – rdelaage
Ligne 2: Ligne 2:
 # Exposer le socket Docker via TLS # Exposer le socket Docker via TLS
  
-### Introduction+## Préambule
  
-Pour certaines opérations, il peut être utile de pouvoir lancer des commandes Docker "à distance". Des exemples sont :+Pour certaines opérations, il peut être utile de pouvoir lancer des commandes Docker à distance. Par exemple, les [[technique:graph_services|graphes des services]] sont construits de manière centralisée en récupérant des informations sur les conteneurs qui tournent, à distance. Une chaîne d'intégration aurait besoin de lancer des commandes à distance.
  
-* [Construction des schémas de l'infrastructure](https://wiki.picasoft.net/doku.php?id=infrastructure:architecture_globale)+Pour ce faire, l'idée est d'exposer le socket Docker (qui permet d'effectuer toutes les opérations possibles avec Docker) à l'extérieur. 
  
-Pour ce faire, l'idée est d'exposer le socket Docker (qui permet d'effectuer toutes les opérations possibles avec Docker) à l'extérieur. Pour des raisons de sécurité élémentaires, on l'expose via TLS.+<bootnote warning>Exposer le socket Docker à l'extérieur revient à donner des accès `root` à quiconque pourra discuter avec lui. Il est donc essentiel d'utiliser TLS pour le sécuriser proprement.</bootnote>
  
 Pour pouvoir communiquer avec le socket Docker depuis l'extérieur, les éléments suivants sont nécessaires : Pour pouvoir communiquer avec le socket Docker depuis l'extérieur, les éléments suivants sont nécessaires :
Ligne 16: Ligne 16:
 * Une clé privée client permettant de signer les messages * Une clé privée client permettant de signer les messages
  
-Pour ce faire, il faut créer une autorité de certification (CA) côté serveur et générer l'ensemble des éléments ci-dessus. +<bootnote>La clé privée est l'équivalent d'une clé privée SSH, qui est plus sûre qu'un mot de passe. Le certificat client est une sorte de carte d'identité du client, et ne peut être émis que par l'instance de Docker accessible à l'extérieur.</bootnote>
-Ces éléments seront créés dans `/DATA/docker/remote` et appartiendront à `root:docker`. Pour l'instant, les machines concernées sont :+
  
-* `pica01` +Pour ce faire, il faut créer une autorité de certification (CA) côté serveur et générer l'ensemble de ces éléments.
-* `pica02` +
-* `pica01-test`+
  
-Ces certificats ont une durée de vie qui a été fixée à un an. Il conviendra donc de les renouveler et de les mettre à jour sur les serveurs **et** les clients concernés tous les ans. Un tutoriel complet est disponible [dans la documentation officielle](https://docs.docker.com/engine/security/https/), nous en reprenons les éléments principaux.+<bootnote important>On crée ces éléments dans `/DATA/docker/remote`, ils appartiendront à `root` avec le groupe `docker`, et seront en `u=rw,g=r`.</bootnote> 
 + 
 +<bootnote>On a fixé arbitrairement la durée de vie des certificats à un an. Il conviendra donc de les renouveler et de les mettre à jour sur les serveurs **et** les clients concernés tous les ans.</bootnote> 
 + 
 +<bootnote web>Un tutoriel complet est disponible [dans la documentation officielle](https://docs.docker.com/engine/security/https/), nous en reprenons les éléments principaux.</bootnote>
  
 Une bonne pratique est de ne pas ré-utiliser les certificats et clés clientes pour des clients multiples : générez autant de certificats que de clients. Une bonne pratique est de ne pas ré-utiliser les certificats et clés clientes pour des clients multiples : générez autant de certificats que de clients.
  
-Notons enfin que les `passphrases` chiffrant les clés privées des autorités de certification, celles-là même qui permettent de produire des certificats serveur et client, sont mises à disposition sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass) pour les clés autorisées, avec la nomenclature `Tech/Keys/<serveur>/ca-key.pem`.+## Créer une clé privée pour la CA 
 + 
 +C'est la clé la plus importante, puisqu'elle permet de créer les certificats. Si elle est compromise, n'importe qui pourrait créer un certificat client illégitime. 
 +C'est pourquoi on la protegera avec un mot de passe. 
 + 
 +On génère la clé : 
 + 
 +```bash 
 +openssl genrsa -aes256 -out ca-key.pem 4096 
 +```
  
-L'ensemble des opérations expliquées plus bas, sauf indication contraire, se passent dans le dossier `/DATA/docker/remote`, sur le serveur concerné (exemple : `pica01-test.picasoft.net`)+Générer la clé avec [[asso:tuto:vaultwarden|vaultwarden]], avec la nomenclature `Tech/Keys/<serveur>/ca-key.pem`.
  
-### Renouvellement de la CA+## Créer ou renouveller la CA
  
 On crée la CA à partir de la clé privée existante, `ca-key.pem`, à l'aide de la commande suivante : On crée la CA à partir de la clé privée existante, `ca-key.pem`, à l'aide de la commande suivante :
Ligne 49: Ligne 59:
 * `Email Address` : `picasoft@assos.utc.fr` * `Email Address` : `picasoft@assos.utc.fr`
  
 +<bootnote>
 L'autorité de certification ainsi obtenue permettra de créer des certificats (serveur ou client). Elle n'est **jamais** utilisée pour chiffrer les communications. L'autorité de certification ainsi obtenue permettra de créer des certificats (serveur ou client). Elle n'est **jamais** utilisée pour chiffrer les communications.
 +</bootnote>
  
-### Renouvellement du certificat serveur+## Création du certificat serveur
  
 Ce certificat est spécifié lors du lancement du démon Docker, et a plusieurs rôles : Ce certificat est spécifié lors du lancement du démon Docker, et a plusieurs rôles :
Ligne 127: Ligne 139:
 Renouvelez l'opération pour l'ensemble des clients. Renouvelez l'opération pour l'ensemble des clients.
  
-### Relancer le démon Docker+## Configurer le démon Docker 
 + 
 +Vérifier que le démon Docker est bien configuré pour [[technique:docker:admin:config#drop_in|démarrer avec TLS et utiliser le certificat généré]]. 
 + 
 +## Relancer le démon Docker
  
 Avant toute chose, il est **indispensable** de donner des permissions propres à tout ce qui a été généré : Avant toute chose, il est **indispensable** de donner des permissions propres à tout ce qui a été généré :
  
 ```bash ```bash
-$ cd /DATA/docker/remote +cd /DATA/docker/remote 
-$ sudo chown -R root:docker . +sudo chown -R root:docker . 
-$ sudo chmod -R u=rwX,g=rwX .+sudo chmod -R u=rwX,g=rwX .
 ``` ```
  
-Il faut relancer le démon Docker avec les nouveaux certificats. Attention, **prévenez l'équipe technique et choisissez votre moment**, puisque tous les conteneurs seront redémarrés. Pour ce faire :+Il faut relancer le démon Docker avec les nouveaux certificats.
  
 ```bash ```bash
-$ sudo systemctl restart docker +sudo systemctl restart docker 
-$ systemctl status docker+systemctl status docker
 ``` ```
  
-On vérifie dans les logs que tout s'est bien passé. Un petit `docker ps` ne fait pas de mal. +## Utilisation des certificats clients
- +
-Vous remarquerez qu'on ne spécifie nulle part au démon Docker quels certificats il faut utiliser. C'est parce que la configuration du service `docker` utilise le système de `drop-in` pour rajouter des paramètres. Par exemple, sur `pica01-test`, le fichier `/etc/systemd/system/docker.service.d/override.conf` contient : +
- +
-``` +
-[Service] +
-ExecStart= +
-ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/DATA/docker/remote/ca.pem --tlscert=/DATA/docker/remote/server-cert.pem --tlskey=/DATA/docker/remote/server-key.pem --host=tcp://0.0.0.0:2376 --host=fd:// +
- +
-[Unit] +
-Requires=docker.socket +
-``` +
- +
-On retrouve bien les paramètres attendus. +
- +
-### Utilisation des certificats clients+
  
 Depuis le serveur concerné, récupérez les fichiers suivants : Depuis le serveur concerné, récupérez les fichiers suivants :
Ligne 170: Ligne 171:
  
 ```bash ```bash
-tar -cvf certs.tar ca.pem client+tar -cvf certs.tar ca.pem <client>
 gpg -c certs.tar gpg -c certs.tar
 rm certs.tar rm certs.tar
Ligne 185: Ligne 186:
  
 ```bash ```bash
-gpg /tmp/certs.tar.gpg +cd /tmp 
-tar -xvf /tmp/certs.tar+gpg certs.tar.gpg 
 +tar -xvf certs.tar
 ``` ```
  
Ligne 192: Ligne 194:
  
 ```bash ```bash
-docker --tlsverify --tlscacert=/tmp/ca.pem --tlscert=/tmp/<client>/<client>-cert.pem --tlskey=/tmp/<client>/<client>-key.pem -H=<serveur>.picasoft.net:2376 version+docker --tlsverify --tlscacert=/tmp/ca.pem --tlscert=/tmp/client/<client>-cert.pem --tlskey=/tmp/client/<client>-key.pem -H=<serveur>.picasoft.net:2376 version
 ``` ```
  
 Si tout se passe bien, vous obtenez la version de Docker. **Vérifiez qu'il n'y a aucune erreur**. Si tout se passe bien, vous obtenez la version de Docker. **Vérifiez qu'il n'y a aucune erreur**.
  
-Enfin, il est nécessaire de mettre à jour les fichiers les services qui l'utilisent : on se référera à leur documentation.+<bootnote>Il est nécessaire de mettre à jour les fichiers des services qui l'utilisent : on se référera à leur documentation.</bootnote>
  
  • technique/docker/admin/socket-certs.1602683593.txt.gz
  • de qduchemi