Différences
Ci-dessous, les différences entre deux révisions de la page.
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/13 19:17] – ↷ Page déplacée et renommée de technique:adminsys:docker:docker-socket-certs à technique:docker:admin:socket-certs qduchemi | technique:docker:admin:socket-certs [2022/09/23 10:00] (Version actuelle) – rdelaage | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ## Renouvellement des certificats pour se connecter à distance au socket Docker | + | {{indexmenu_n> |
+ | # Exposer le socket Docker | ||
- | ### Introduction | + | ## Préambule |
- | Pour certaines opérations, | + | Pour certaines opérations, |
- | * [Construction des schémas de l'infrastructure](https:// | + | Pour ce faire, |
- | Pour ce faire, l' | + | < |
Pour pouvoir communiquer avec le socket Docker depuis l' | Pour pouvoir communiquer avec le socket Docker depuis l' | ||
Ligne 15: | 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 | + | < |
- | Ces éléments seront créés dans `/ | + | |
- | * `pica01` | + | Pour ce faire, il faut créer une autorité de certification (CA) côté serveur et générer l' |
- | * `pica02` | + | |
- | * `pica01-test` | + | |
- | Ces certificats ont une durée de vie qui a été fixée | + | < |
+ | |||
+ | < | ||
+ | |||
+ | < | ||
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 | + | ## Créer une clé privée pour la CA |
+ | |||
+ | C'est la clé la plus importante, puisqu' | ||
+ | C'est pourquoi on la protegera | ||
+ | |||
+ | On génère | ||
+ | |||
+ | ```bash | ||
+ | openssl genrsa -aes256 -out ca-key.pem | ||
+ | ``` | ||
- | L' | + | Générer la clé avec [[asso: |
- | ### Renouvellement de la CA | + | ## Créer ou renouveller |
On crée la CA à partir de la clé privée existante, `ca-key.pem`, | On crée la CA à partir de la clé privée existante, `ca-key.pem`, | ||
Ligne 48: | Ligne 59: | ||
* `Email Address` : `picasoft@assos.utc.fr` | * `Email Address` : `picasoft@assos.utc.fr` | ||
+ | < | ||
L' | L' | ||
+ | </ | ||
- | ### Renouvellement | + | ## Création |
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 126: | Ligne 139: | ||
Renouvelez l' | Renouvelez l' | ||
- | ### Relancer le démon Docker | + | ## Configurer le démon Docker |
+ | |||
+ | Vérifier que le démon Docker est bien configuré pour [[technique: | ||
+ | |||
+ | ## 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 / | + | cd / |
- | $ 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. | + | 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`, | + | |
- | + | ||
- | ``` | + | |
- | [Service] | + | |
- | ExecStart= | + | |
- | ExecStart=/ | + | |
- | + | ||
- | [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 169: | Ligne 171: | ||
```bash | ```bash | ||
- | tar -cvf certs.tar ca.pem client | + | tar -cvf certs.tar ca.pem |
gpg -c certs.tar | gpg -c certs.tar | ||
rm certs.tar | rm certs.tar | ||
Ligne 184: | 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 191: | Ligne 194: | ||
```bash | ```bash | ||
- | docker --tlsverify --tlscacert=/ | + | docker --tlsverify --tlscacert=/ |
``` | ``` | ||
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 | + | < |