Configurer un proxy pour le démon dockerd

Si le démon dockerd possède 3 variables d’environnement pour sa configuration de proxy (HTTP_PROXY, HTTPS_PROXY et NOPROXY), l’accès à une Registry externe (celle du Hub de Docker par exemple) se fait forcément en HTTPS… et c’est là que les petits problèmes commencent…

Pour configurer les variables d’environnement avec un démon géré par systemd, créez le répertoire /etc/systemd/system/docker.service.d puis ajoutez le fichier proxy.conf contenant la définition des variables d’environnement. Par exemple :

[Service]
Environment="HTTP_PROXY=http://mon_proxy:3128"
Environment="HTTPS_PROXY=http://mon_proxy:3129"
Environment="NO_PROXY=localhost,127.0.0.1,172.17.0.1,172.30.1.1"

Puis exécutez les commandes suivantes :

# systemctl dameon-reload
# systemctl restart docker

et un petit test….

$ docker search ubuntu

Attention :

• si votre proxy utilise un certificat auto-signé, vous devrez rajouter l’option suivante dans la configuration du démon

--insecure-registry proxy:port

• si votre proxy utilise un certificat signé par une CA, exécutez les commandes suivantes :

$ sudo cp mon_cert.crt /etc/pki/ca-trust/source/anchors

$ sudo update-ca-trust extract

Effectuer la rotation des clés des serveurs SSHD en douceur

Depuis la version 6.8 de OpenSSH (disponible à partir de la RHEL/CentOS 7.4), il est possible d’effectuer des rotations des clés de serveurs pour le service SSH, tout en douceur pour l’utilisateur.

Quel est le problème ?

Vous savez bien que lors d’un changement de clés côté serveur, le client va devoir valider l’empreinte de la nouvelle clé, ce qui risque de surprendre l’utilisateur consciencieux qui va se croire victime d’une attaque Mitm !

Avec la nouvelle version de OpenSSH, plus de risque d’apeurer vos utilisateurs ou clients.

La solution :

• générez vos nouvelles clés sous /etc/ssh/, avec l’algorithme ecdsa sur 521 bits par exemple:

  # ssh-keygen -t ecdsa -b 521

• ajoutez les nouvelles directives HostKey après celles qui existent déjà
• demandez aux utilisateurs d’ajouter l’option « UpdateHostKeys yes » (ou « ask ») dans la configuration de leur client SSH ou bien d’ajouter cette option. Par exemple:

  $ ssh -o UpdateHostKeys=ask serveur

• lors de la connexion au serveur, le client SSH va aspirer toutes les clés du serveurs et mettre le fichier known_hosts à jour
• après un « certain temps », estimant que tous les utilisateurs ont aspiré les nouvelles clés, il ne reste plus qu’à l’administrateur qu’à supprimer les anciennes clés !

Commandes et configuration de proxy

Les développeurs des commandes yum, pip, apt-get, docker et autres se mettront-ils un jour d’accord pour unifier la configuration et l’utilisation d’un Proxy ? Comme je m’y perds, voici un pense-bête qui donne un exemple de marche à suivre pour configurer quelques commandes usuelles.

1. La commande pip :
   en ligne de commande, ajoutez les options suivantes :

   --proxy http://<login>:<user>@<proxy>:<port> --trusted-host pypi.python.org

   ou bien dans votre fichier pip.conf, ajoutez les paramètres suivants :

   [global]
   proxy = http://<user>:<password>@<proxy>:<port>
   trusted-host = pypi.python.org
   

2. La commande yum :
   dans le fichier /etc/yum.conf, ajoutez les paramètres suivants :

   proxy=http://<proxy>:<port>
   proxy_username=<user>
   proxy_password=<password>
   

3. La commande docker :
   il faut définir les variables d’environnement http_proxy et https_proxy avant de lancer le démon. Par exemple dans le fichier /etc/sysconfig/docker.

sudoedit pour éditer un fichier en toute sérénité

Il est parfois nécessaire de déléguer la possibilité de modifier un fichier « système » à un autre utilisateur que root, par exemple bob. Une solution serait d’ajouter une ACL au fichier (par exemple, le fichier /etc/motd), mais je trouve que la gestion des ACL est pénible… laissons-ça aux bons soins de Samba pour faire plaisir aux utilisateurs de Windows.

Si on souhaite utiliser la commande sudo, vous savez certainement que la ligne suivante ne doit pas être placée dans le fichier /etc/sudoers :

bob ALL=(ALL) NOPASSWD: /usr/bin/vi /etc/motd

Pourquoi ? Simplement parce que bob va pouvoir lancer l’éditeur vi en-tant-que-root et donc qu’il pourra éditer d’autres fichiers (avec la commande « :e » de vi) ou bien il pourra obtenir un shell bash toujours avec le compte root (avec la commande « :!bash« ).

Pour éviter l’écueil du lancement d’un shell (ou de toute autre commande), on pourrait ajouter le flag NOEXEC dans le fichier /etc/sudoers, mais cela n’évite pas l’édition d’un autre fichier.

Certains pensent que remplacer vi par nano résoud le problème :

bob ALL=(ALL) NOPASSWD: /usr/bin/nano /etc/motd

Mais avec nano, je peux sauver le contenu du fichier édité sous un nom quelconque et donc je peux changer le contenu de n’importe quel fichier ! Ce n’est pas la bonne solution.

La bonne solution consiste à utiliser la commande sudoedit, équivalente à sudo -e :

bob ALL=(ALL) NOPASSWD: sudoedit /etc/motd

L’utilisateur peut modifier le fichier /etc/motd ainsi :

bob$ sudoedit /etc/motd

Même si l’éditeur par défaut est vi, le lancement d’un shell produira un shell fonctionnant avec le compte de bob et l’édition d’un fichier protégé ne sera pas possible. Pourquoi ? Parce que sudoedit copie le fichier original dans un fichier temporaire appartenant à bob et qu’il n’a besoin des privilèges de root que pour recopier ce fichier temporaire à la place du fichier original, lors de la sauvegarde du contenu du fichier. Le reste du temps, sudoedit (l’éditeur en fait) est exécuté avec le compte de bob, ce que montre l’affichage de la commande ps -edf par exemple.

Démarrer RHEL/Centos7 sans mot de passe « root »

Contrairement aux anciennes versions et autres distributions Linux pour lesquelles l’ajout du paramètre init=/bin/bash dans les options du noyau suffisait, ces distributions nécessitent l’une des deux options suivantes :

rd.break
init=/sysroot/bin/sh

Notez que « rd.break » stoppe l’exécution du boot lorsque le contrôle passe de initramfs à systemd. Dans les deux cas, il faudra faire un « # chroot /sysroot » et remonter le système de fichiers racine en rw (on aurait pu aussi passer l’option « rw » directement au noyau)