Isolation des conteneurs par namespaces

Cette page indique les étapes supplémentaires nécessaires pour isoler les conteneurs avec les user namespace Linux.

S’assurer que Docker et Cyberwatch sont installés

Créer l’utilisateur cyberwatch :

sudo useradd --create-home --shell /bin/bash cyberwatch

Éditer le fichier /etc/subuid :
```
cyberwatch:231072:65536
cyberwatch:1001:1
```
La première ligne permet de définir le mappage des user/groups ids dans un user namespace. Cette ligne est généralement ajoutée automatiquement par le système lors de la création de l’utilisateur, mais certains systèmes ne le font pas automatiquement (certaines versions de CentOS par exemple).
Par exemple, cyberwatch:231072:65536 signifie que l’utilisateur cyberwatch peut utiliser 65536 user ids à partir de l’id 231072.
La ligne cyberwatch:1001:1 permet de faire en sorte que les fichiers créés par root appartiennent à l’utilisateur avec l’id 1001 (à remplacer par l’id de l’utilisateur cyberwatch).

Éditer le fichier /etc/subgid :

cyberwatch:231072:65536
cyberwatch:1001:1

Redémarrer le serveur pour que les modifications soient prises en compte :
```
sudo reboot
```

Configurer docker pour activer l’option userns-remap :

cat >> /etc/docker/daemon.json <<EOL
{
  "userns-remap": "cyberwatch"
}
EOL

Redémarrer docker :
```
systemctl restart docker
```

Dossier des certificats nginx (Cyberwatch 5.31 et versions ultérieures)

À partir de Cyberwatch 5.31, les certificats de nginx sont stockés dans le dossier /etc/cyberwatch/ssl de l’hôte au lieu d’un volume Docker. Au démarrage, Cyberwatch attribue ce dossier à l’utilisateur root (UID et GID 0) et en restreint l’accès à son seul propriétaire.

Avec userns-remap, l’UID 0 de l’hôte ne correspond pas à root à l’intérieur des conteneurs. Le conteneur nginx ne peut alors plus lire ses certificats, ce qui l’empêche de démarrer (redémarrages en boucle du conteneur, interface HTTPS indisponible).

Pour corriger ce comportement, il faut indiquer à Cyberwatch l’UID et le GID de l’hôte correspondant à root dans les conteneurs.

Identifier l’UID et le GID de l’hôte correspondant à root dans les conteneurs. Lorsque userns-remap est actif, Docker les fait apparaître dans le nom de son répertoire de données actif :
```
docker info --format ''
```
La commande renvoie un chemin de la forme /var/lib/docker/<uid>.<gid>, par exemple /var/lib/docker/165536.165536 : root dans les conteneurs correspond alors à l’UID 165536 et au GID 165536 sur l’hôte.
Renseigner ces valeurs dans le fichier /etc/cyberwatch/config.env :
```
CBW_NGINX_UID=165536
CBW_NGINX_GID=165536
```
Redémarrer Cyberwatch pour appliquer les nouvelles permissions :
```
sudo cyberwatch restart
```

Troubleshooting

Les problèmes pouvant découler de l’activation de userns-remap sont généralement liés aux droits sur les volumes.

Il peut être intéressant de consulter les logs du conteneur de base de données afin d’écarter les problèmes de permissions :

sudo cyberwatch logs db

Depuis Cyberwatch 5.31, si le conteneur nginx ne démarre pas ou si l’interface HTTPS est indisponible après l’activation de userns-remap, vérifier la configuration de CBW_NGINX_UID et CBW_NGINX_GID (voir la section Dossier des certificats nginx ci-dessus). Les logs du conteneur nginx aident au diagnostic :

sudo cyberwatch logs nginx