Aïllament dels contenidors amb espais de noms

Aquesta pàgina indica els passos addicionals necessaris per aïllar els contenidors amb els espais de noms d’usuari (user namespaces) de Linux.

El procediment varia segons si la instància de Cyberwatch ja disposa de volums Docker que contenen dades o no:

Instància sense volums existents (instal·lació nova): seguiu la secció «Aïllament d’una instància sense volums existents».
Instància ja instal·lada (volums existents): seguiu la secció «Aïllament d’una instància amb volums existents».

Aïllament d’una instància sense volums existents

Assegureu-vos que Docker i Cyberwatch estan instal·lats

Creeu l’usuari cyberwatch:

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

Comproveu que l’usuari cyberwatch disposa d’un interval d’identificadors als fitxers /etc/subuid i /etc/subgid:
```
grep '^cyberwatch:' /etc/subuid /etc/subgid
```
L’ordre ha de retornar una sola línia per fitxer, per exemple:
```
/etc/subuid:cyberwatch:231072:65536
/etc/subgid:cyberwatch:231072:65536
```
cyberwatch:231072:65536 vol dir que l’usuari cyberwatch pot utilitzar 65536 identificadors d’usuari a partir de l’identificador 231072: root als contenidors correspon aleshores a l’identificador 231072 a l’amfitrió.
Editeu el fitxer /etc/docker/daemon.json per activar l’opció userns-remap:
```
{
  "userns-remap": "cyberwatch"
}
```
Si el fitxer ja existeix, afegiu la clau userns-remap a l’objecte JSON existent.
Comproveu la configuració de Docker:
```
sudo dockerd --validate --config-file /etc/docker/daemon.json
```
L’ordre ha de retornar configuration OK.
Reinicieu Docker:
```
sudo systemctl restart docker
```
Indiqueu les variables CBW_NGINX_UID i CBW_NGINX_GID seguint la secció Carpeta dels certificats de nginx.

En una instal·lació nova, continueu després la instal·lació de Cyberwatch amb l’ordre cyberwatch configure.

Aïllament d’una instància amb volums existents

L’activació de userns-remap canvia la ubicació de les dades de Docker (/var/lib/docker/<uid>.<gid>): aleshores Docker crea volums nous buits, no associats als volums existents. Les imatges també s’han de tornar a baixar: preveieu l’espai de disc necessari, ja que les dades antigues de Docker es queden al disc.

Sense una còpia de seguretat de la base de dades feta abans de l’aïllament i restaurada després, les dades de la instància no es recuperen i la instància s’inicia buida.

Per activar l’aïllament en una instància de Cyberwatch ja instal·lada sense perdre’n les dades:

Feu una còpia de seguretat de Cyberwatch abans de fer cap modificació, seguint el procediment de còpia de seguretat i restauració de Cyberwatch.
Configureu l’aïllament seguint tots els passos de la secció «Aïllament d’una instància sense volums existents» anterior.
En una instància fora de línia, torneu a carregar les imatges a Docker: les que es van carregar abans de l’aïllament ja no són visibles.
Torneu a configurar Cyberwatch:
```
sudo cyberwatch configure
```
Restaureu la còpia de seguretat feta al pas 1, seguint el procediment de còpia de seguretat i restauració de Cyberwatch.

Carpeta dels certificats de nginx (Cyberwatch 5.31 i versions posteriors)

A partir de Cyberwatch 5.31, els certificats de nginx s’emmagatzemen a la carpeta /etc/cyberwatch/ssl de l’amfitrió en lloc d’un volum Docker. En iniciar-se, Cyberwatch assigna aquesta carpeta a l’usuari que executa nginx al seu contenidor i en restringeix l’accés només a aquest usuari:

Cyberwatch 5.31: root (UID i GID 0)
Cyberwatch 5.32 i versions posteriors: nginx (UID i GID 101)

Amb userns-remap, aquests UID i GID no corresponen al mateix usuari a l’amfitrió i als contenidors. Aleshores, el contenidor nginx ja no pot llegir els seus certificats, cosa que li impedeix iniciar-se (reinicis en bucle del contenidor, interfície HTTPS no disponible).

Per corregir aquest comportament, cal indicar a Cyberwatch l’UID i el GID de l’amfitrió que corresponen a l’usuari nginx dels contenidors.

Identifiqueu l’UID i el GID de l’amfitrió que corresponen a root als contenidors. Quan userns-remap està actiu, Docker els mostra al nom del seu directori de dades actiu:
```
docker info --format '{{.DockerRootDir}}'
```
L’ordre retorna un camí de la forma /var/lib/docker/<uid>.<gid>, per exemple /var/lib/docker/231072.231072: root als contenidors correspon aleshores a l’UID 231072 i al GID 231072 a l’amfitrió.
Deduïu-ne els valors que cal indicar segons la versió de Cyberwatch:
- Cyberwatch 5.31: l’UID i el GID de root, és a dir, 231072 a l’exemple
- Cyberwatch 5.32 i versions posteriors: l’UID i el GID de root més 101, és a dir, 231173 a l’exemple
Indiqueu aquests valors al fitxer /etc/cyberwatch/config.env, per exemple per a Cyberwatch 5.32 i versions posteriors:
```
CBW_NGINX_UID=231173
CBW_NGINX_GID=231173
```
Reinicieu Cyberwatch per aplicar els permisos nous:
```
sudo cyberwatch restart
```
Quan configureu l’aïllament, aquest pas no és necessari: l’ordre cyberwatch configure del procediment aplica els permisos nous.

Abans d’actualitzar una instància aïllada de Cyberwatch 5.31 a la versió 5.32 o a una versió posterior, manualment o automàticament, afegiu 101 als valors de CBW_NGINX_UID i CBW_NGINX_GID del fitxer /etc/cyberwatch/config.env. Cyberwatch 5.31 també funciona amb aquests valors, que s’apliquen en el reinici de l’actualització.

Resolució de problemes

Els problemes que pot causar l’activació de userns-remap normalment estan relacionats amb els drets sobre els volums.

Si, després d’activar userns-remap en una instància ja instal·lada, l’aplicació s’inicia sense les seves dades, vol dir que s’han creat volums nous: restaureu la còpia de seguretat feta abans de l’aïllament (vegeu la secció «Aïllament d’una instància amb volums existents»).

Pot ser útil consultar els registres del contenidor de base de dades per descartar problemes de permisos:

sudo cyberwatch logs db

Des de Cyberwatch 5.31, si el contenidor nginx no s’inicia o si la interfície HTTPS no està disponible després d’activar userns-remap o després d’una actualització, comproveu la configuració de CBW_NGINX_UID i CBW_NGINX_GID (vegeu la secció Carpeta dels certificats de nginx). Els registres del contenidor nginx ajuden a fer el diagnòstic:

sudo cyberwatch logs nginx

Un error Permission denied al fitxer /etc/nginx/ssl/nginx.crt indica valors incorrectes.