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

Editar el archivo /etc/subuid:
```
cyberwatch:231072:65536
cyberwatch:1001:1
```
La primera línea permite definir el mapeo de los user/groups ids en un user namespace. Esta línea generalmente es añadida automáticamente por el sistema al crear el usuario, pero algunos sistemas no lo hacen automáticamente (algunas versiones de CentOS, por ejemplo).
Por ejemplo, cyberwatch:231072:65536 significa que el usuario cyberwatch puede utilizar 65536 user ids a partir del id 231072.
La línea cyberwatch:1001:1 permite que los archivos creados por root pertenezcan al usuario con el id 1001 (a reemplazar por el id del usuario cyberwatch).

Edite el archivo /etc/subgid:

cyberwatch:231072:65536
cyberwatch:1001:1

Reinicie el servidor para que los cambios se apliquen:
```
sudo reboot
```

Configure Docker para activar la opción userns-remap:

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

Reinicie Docker:
```
systemctl restart docker
```

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.

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.
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 root (UID y GID 0) y restringe el acceso únicamente a su propietario.

Con userns-remap, el UID 0 del host no corresponde a root 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 a root dentro 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/165536.165536: root dentro de los contenedores corresponde entonces al UID 165536 y al GID 165536 en el host.
Indique estos valores en el archivo /etc/cyberwatch/config.env:
```
CBW_NGINX_UID=165536
CBW_NGINX_GID=165536
```
Reiniciar Cyberwatch para aplicar los nuevos permisos:
```
sudo cyberwatch restart
```

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, verifique la configuración de CBW_NGINX_UID y CBW_NGINX_GID (ver la sección Carpeta de certificados nginx anterior). Los logs del contenedor nginx ayudan al diagnóstico:

sudo cyberwatch logs nginx