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

Vérifier que l’utilisateur cyberwatch dispose d’une plage d’ids dans les fichiers /etc/subuid et /etc/subgid :
```
grep '^cyberwatch:' /etc/subuid /etc/subgid
```
La commande doit renvoyer une seule ligne par fichier, par exemple :
```
/etc/subuid:cyberwatch:231072:65536
/etc/subgid:cyberwatch:231072:65536
```
cyberwatch:231072:65536 signifie que l’utilisateur cyberwatch peut utiliser 65536 user ids à partir de l’id 231072 : root dans les conteneurs correspond alors à l’id 231072 sur l’hôte.
Éditer le fichier /etc/docker/daemon.json pour activer l’option userns-remap :
```
{
  "userns-remap": "cyberwatch"
}
```
Si le fichier existe déjà, ajouter la clé userns-remap à l’objet JSON existant.
Vérifier la configuration de Docker :
```
sudo dockerd --validate --config-file /etc/docker/daemon.json
```
La commande doit renvoyer configuration OK.
Redémarrer docker :
```
sudo systemctl restart docker
```
Renseigner les variables CBW_NGINX_UID et CBW_NGINX_GID en suivant la section Dossier des certificats nginx.

Pour une nouvelle installation, poursuivre ensuite l’installation de Cyberwatch avec la commande cyberwatch configure.

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. Les images doivent aussi être téléchargées à nouveau : prévoir l’espace disque nécessaire, les anciennes données Docker restant sur le disque.

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.
Sur une instance hors ligne, charger à nouveau les images dans Docker : celles chargées avant l’isolation ne sont plus visibles.
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 qui exécute nginx dans son conteneur et en restreint l’accès à ce seul utilisateur :

Cyberwatch 5.31 : root (UID et GID 0)
Cyberwatch 5.32 et versions ultérieures : nginx (UID et GID 101)

Avec userns-remap, ces UID et GID ne correspondent pas au même utilisateur sur l’hôte et dans les 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 à l’utilisateur nginx des 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 '{{.DockerRootDir}}'
```
La commande renvoie un chemin de la forme /var/lib/docker/<uid>.<gid>, par exemple /var/lib/docker/231072.231072 : root dans les conteneurs correspond alors à l’UID 231072 et au GID 231072 sur l’hôte.
En déduire les valeurs à renseigner selon la version de Cyberwatch :
- Cyberwatch 5.31 : l’UID et le GID de root, soit 231072 dans l’exemple
- Cyberwatch 5.32 et versions ultérieures : l’UID et le GID de root augmentés de 101, soit 231173 dans l’exemple
Renseigner ces valeurs dans le fichier /etc/cyberwatch/config.env, par exemple pour Cyberwatch 5.32 et versions ultérieures :
```
CBW_NGINX_UID=231173
CBW_NGINX_GID=231173
```
Redémarrer Cyberwatch pour appliquer les nouvelles permissions :
```
sudo cyberwatch restart
```
Lors de la mise en place de l’isolation, cette étape est inutile : la commande cyberwatch configure de la procédure applique les nouvelles permissions.

Avant de mettre à jour une instance isolée de Cyberwatch 5.31 vers la version 5.32 ou une version ultérieure, manuellement ou automatiquement, ajouter 101 aux valeurs de CBW_NGINX_UID et CBW_NGINX_GID du fichier /etc/cyberwatch/config.env. Cyberwatch 5.31 fonctionne aussi avec ces valeurs, qui sont appliquées au redémarrage de la mise à jour.

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 ou après une mise à jour, vérifier la configuration de CBW_NGINX_UID et CBW_NGINX_GID (voir la section Dossier des certificats nginx). Les logs du conteneur nginx aident au diagnostic :

sudo cyberwatch logs nginx

Une erreur Permission denied sur le fichier /etc/nginx/ssl/nginx.crt indique des valeurs incorrectes.