Isolation des conteneurs par namespaces

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

La procédure diffère selon que l’instance Cyberwatch dispose déjà de volumes Docker contenant des données ou non :

Instance sans volume existant (nouvelle installation) : suivre la section « Isolation d’une instance sans volume existant ».
Instance déjà installée (volumes existants) : suivre la section « Isolation d’une instance avec volumes existants ».

Isolation d’une instance sans volume existant

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
```

Isolation d’une instance avec volumes existants

L’activation de userns-remap change l’emplacement des données Docker (/var/lib/docker/<uid>.<gid>) : Docker crée alors de nouveaux volumes vides, non mappés sur les volumes existants.

Sans backup de la base de données réalisé avant l’isolation puis restauré après, les données de l’instance ne sont pas reprises et l’instance démarre vide.

Pour activer l’isolation sur une instance Cyberwatch déjà installée sans perdre ses données :

Réaliser un backup de Cyberwatch avant toute modification, en suivant la procédure de backup et restauration de Cyberwatch.
Mettre en place l’isolation en suivant l’ensemble des étapes de la section « Isolation d’une instance sans volume existant » ci-dessus.
Reconfigurer Cyberwatch :
```
sudo cyberwatch configure
```
Restaurer le backup réalisé à l’étape 1, en suivant la procédure de backup et restauration de Cyberwatch.

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.

Si, après activation de userns-remap sur une instance déjà installée, l’application démarre sans ses données, cela signifie que de nouveaux volumes ont été créés : restaurer le backup réalisé avant isolation (voir la section « Isolation d’une instance avec volumes existants »).

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