Aislamiento de contenedores por namespaces

Esta página indica los pasos adicionales necesarios para aislar los contenedores con los user namespace de Linux.

El procedimiento difiere según si la instancia de Cyberwatch ya dispone de volúmenes Docker que contienen datos o no:

Instancia sin volumen existente (nueva instalación): siga la sección «Aislamiento de una instancia sin volumen existente».
Instancia ya instalada (volúmenes existentes): siga la sección «Aislamiento de una instancia con volúmenes existentes».

Aislamiento de una instancia sin volumen existente

Asegúrese de que Docker y Cyberwatch están instalados

Cree el usuario cyberwatch:

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

Verifique que el usuario cyberwatch dispone de un rango de ids en los archivos /etc/subuid y /etc/subgid:
```
grep '^cyberwatch:' /etc/subuid /etc/subgid
```
El comando debe devolver una sola línea por archivo, por ejemplo:
```
/etc/subuid:cyberwatch:231072:65536
/etc/subgid:cyberwatch:231072:65536
```
cyberwatch:231072:65536 significa que el usuario cyberwatch puede utilizar 65536 user ids a partir del id 231072: root dentro de los contenedores corresponde entonces al id 231072 en el host.
Edite el archivo /etc/docker/daemon.json para activar la opción userns-remap:
```
{
  "userns-remap": "cyberwatch"
}
```
Si el archivo ya existe, añada la clave userns-remap al objeto JSON existente.
Verifique la configuración de Docker:
```
sudo dockerd --validate --config-file /etc/docker/daemon.json
```
El comando debe devolver configuration OK.
Reinicie Docker:
```
sudo systemctl restart docker
```
Indique las variables CBW_NGINX_UID y CBW_NGINX_GID siguiendo la sección Carpeta de certificados nginx.

Para una nueva instalación, prosiga después la instalación de Cyberwatch con el comando cyberwatch configure.

Aislamiento de una instancia con volúmenes existentes

La activación de userns-remap cambia la ubicación de los datos de Docker (/var/lib/docker/<uid>.<gid>): Docker crea entonces nuevos volúmenes vacíos, no mapeados sobre los volúmenes existentes. Las imágenes también deben descargarse de nuevo: prevea el espacio en disco necesario, ya que los antiguos datos de Docker permanecen en el disco.

Sin una copia de seguridad de la base de datos realizada antes del aislamiento y restaurada después, los datos de la instancia no se recuperan y la instancia se inicia vacía.

Para activar el aislamiento en una instancia de Cyberwatch ya instalada sin perder sus datos:

Realice una copia de seguridad de Cyberwatch antes de cualquier modificación, siguiendo el procedimiento de backup y restauración de Cyberwatch.
Implemente el aislamiento siguiendo todos los pasos de la sección «Aislamiento de una instancia sin volumen existente» anterior.
En una instancia sin conexión, vuelva a cargar las imágenes en Docker: las cargadas antes del aislamiento ya no son visibles.
Reconfigure Cyberwatch:
```
sudo cyberwatch configure
```
Restaure la copia de seguridad realizada en el paso 1, siguiendo el procedimiento de backup y restauración de Cyberwatch.

Carpeta de certificados nginx (Cyberwatch 5.31 y versiones posteriores)

A partir de Cyberwatch 5.31, los certificados de nginx se almacenan en la carpeta /etc/cyberwatch/ssl del host en lugar de en un volumen Docker. Al arrancar, Cyberwatch asigna esta carpeta al usuario que ejecuta nginx en su contenedor y restringe el acceso únicamente a ese usuario:

Cyberwatch 5.31: root (UID y GID 0)
Cyberwatch 5.32 y versiones posteriores: nginx (UID y GID 101)

Con userns-remap, estos UID y GID no corresponden al mismo usuario en el host y dentro de los contenedores. El contenedor nginx ya no puede leer sus certificados, lo que le impide arrancar (reinicios en bucle del contenedor, interfaz HTTPS no disponible).

Para corregir este comportamiento, hay que indicar a Cyberwatch el UID y el GID del host que corresponden al usuario nginx de los contenedores.

Identifique el UID y el GID del host que corresponden a root dentro de los contenedores. Cuando userns-remap está activo, Docker los muestra en el nombre de su directorio de datos activo:
```
docker info --format '{{.DockerRootDir}}'
```
El comando devuelve una ruta con el formato /var/lib/docker/<uid>.<gid>, por ejemplo /var/lib/docker/231072.231072: root dentro de los contenedores corresponde entonces al UID 231072 y al GID 231072 en el host.
Deduzca los valores que debe indicar según la versión de Cyberwatch:
- Cyberwatch 5.31: el UID y el GID de root, es decir 231072 en el ejemplo
- Cyberwatch 5.32 y versiones posteriores: el UID y el GID de root incrementados en 101, es decir 231173 en el ejemplo
Indique estos valores en el archivo /etc/cyberwatch/config.env, por ejemplo para Cyberwatch 5.32 y versiones posteriores:
```
CBW_NGINX_UID=231173
CBW_NGINX_GID=231173
```
Reiniciar Cyberwatch para aplicar los nuevos permisos:
```
sudo cyberwatch restart
```
Durante la implementación del aislamiento, este paso es innecesario: el comando cyberwatch configure del procedimiento aplica los nuevos permisos.

Antes de actualizar una instancia aislada de Cyberwatch 5.31 a la versión 5.32 o a una versión posterior, manual o automáticamente, añada 101 a los valores de CBW_NGINX_UID y CBW_NGINX_GID del archivo /etc/cyberwatch/config.env. Cyberwatch 5.31 también funciona con estos valores, que se aplican en el reinicio de la actualización.

Troubleshooting

Los problemas que pueden derivarse de la activación de userns-remap suelen estar relacionados con los permisos sobre los volúmenes.

Si, tras la activación de userns-remap en una instancia ya instalada, la aplicación se inicia sin sus datos, significa que se han creado nuevos volúmenes: restaure la copia de seguridad realizada antes del aislamiento (ver la sección «Aislamiento de una instancia con volúmenes existentes»).

Puede ser útil consultar los logs del contenedor de base de datos para descartar problemas de permisos:

sudo cyberwatch logs db

Desde Cyberwatch 5.31, si el contenedor nginx no arranca o si la interfaz HTTPS no está disponible tras la activación de userns-remap o tras una actualización, verifique la configuración de CBW_NGINX_UID y CBW_NGINX_GID (ver la sección Carpeta de certificados nginx). Los logs del contenedor nginx ayudan al diagnóstico:

sudo cyberwatch logs nginx

Un error Permission denied en el archivo /etc/nginx/ssl/nginx.crt indica valores incorrectos.