Isolamento dei container tramite namespace

Questa pagina indica i passaggi aggiuntivi necessari per isolare i container con gli user namespace Linux.

La procedura varia a seconda che l’istanza Cyberwatch disponga già o meno di volumi Docker contenenti dati:

Istanza senza volumi esistenti (nuova installazione): seguire la sezione «Isolamento di un’istanza senza volumi esistenti».
Istanza già installata (volumi esistenti): seguire la sezione «Isolamento di un’istanza con volumi esistenti».

Isolamento di un’istanza senza volumi esistenti

Assicurarsi che Docker e Cyberwatch siano installati

Creare l’utente cyberwatch:

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

Verificare che l’utente cyberwatch disponga di un intervallo di ID nei file /etc/subuid e /etc/subgid:
```
grep '^cyberwatch:' /etc/subuid /etc/subgid
```
Il comando deve restituire una sola riga per file, ad esempio:
```
/etc/subuid:cyberwatch:231072:65536
/etc/subgid:cyberwatch:231072:65536
```
cyberwatch:231072:65536 significa che l’utente cyberwatch può utilizzare 65536 ID utente a partire dall’ID 231072: root nei container corrisponde quindi all’ID 231072 sull’host.
Modificare il file /etc/docker/daemon.json per attivare l’opzione userns-remap:
```
{
  "userns-remap": "cyberwatch"
}
```
Se il file esiste già, aggiungere la chiave userns-remap all’oggetto JSON esistente.
Verificare la configurazione di Docker:
```
sudo dockerd --validate --config-file /etc/docker/daemon.json
```
Il comando deve restituire configuration OK.
Riavviare Docker:
```
sudo systemctl restart docker
```
Inserire le variabili CBW_NGINX_UID e CBW_NGINX_GID seguendo la sezione Directory dei certificati nginx.

Per una nuova installazione, proseguire quindi con l’installazione di Cyberwatch con il comando cyberwatch configure.

Isolamento di un’istanza con volumi esistenti

L’attivazione di userns-remap modifica la posizione dei dati Docker (/var/lib/docker/<uid>.<gid>): Docker crea quindi nuovi volumi vuoti, non mappati sui volumi esistenti. Anche le immagini devono essere scaricate di nuovo: prevedere lo spazio su disco necessario, poiché i vecchi dati Docker restano sul disco.

Senza un backup del database eseguito prima dell’isolamento e ripristinato successivamente, i dati dell’istanza non vengono recuperati e l’istanza si avvia vuota.

Per attivare l’isolamento su un’istanza Cyberwatch già installata senza perderne i dati:

Eseguire un backup di Cyberwatch prima di qualsiasi modifica, seguendo la procedura di backup e ripristino di Cyberwatch.
Configurare l’isolamento seguendo tutti i passaggi della sezione «Isolamento di un’istanza senza volumi esistenti» riportata sopra.
Su un’istanza offline, caricare di nuovo le immagini in Docker: quelle caricate prima dell’isolamento non sono più visibili.
Riconfigurare Cyberwatch:
```
sudo cyberwatch configure
```
Ripristinare il backup eseguito al passaggio 1, seguendo la procedura di backup e ripristino di Cyberwatch.

Directory dei certificati nginx (Cyberwatch 5.31 e versioni successive)

A partire da Cyberwatch 5.31, i certificati di nginx sono memorizzati nella directory /etc/cyberwatch/ssl dell’host anziché in un volume Docker. All’avvio, Cyberwatch assegna questa directory all’utente che esegue nginx nel proprio container e ne limita l’accesso a questo solo utente:

Cyberwatch 5.31: root (UID e GID 0)
Cyberwatch 5.32 e versioni successive: nginx (UID e GID 101)

Con userns-remap, questi UID e GID non corrispondono allo stesso utente sull’host e nei container. Il container nginx non è quindi più in grado di leggere i propri certificati, il che ne impedisce l’avvio (riavvii in loop del container, interfaccia HTTPS non disponibile).

Per correggere questo comportamento, è necessario indicare a Cyberwatch l’UID e il GID dell’host corrispondenti all’utente nginx dei container.

Identificare l’UID e il GID dell’host corrispondenti a root nei container. Quando userns-remap è attivo, Docker li riporta nel nome della propria directory di dati attiva:
```
docker info --format '{{.DockerRootDir}}'
```
Il comando restituisce un percorso del tipo /var/lib/docker/<uid>.<gid>, ad esempio /var/lib/docker/231072.231072: root nei container corrisponde quindi all’UID 231072 e al GID 231072 sull’host.
Dedurne i valori da inserire in base alla versione di Cyberwatch:
- Cyberwatch 5.31: l’UID e il GID di root, ovvero 231072 nell’esempio
- Cyberwatch 5.32 e versioni successive: l’UID e il GID di root aumentati di 101, ovvero 231173 nell’esempio
Inserire questi valori nel file /etc/cyberwatch/config.env, ad esempio per Cyberwatch 5.32 e versioni successive:
```
CBW_NGINX_UID=231173
CBW_NGINX_GID=231173
```
Riavviare Cyberwatch per applicare le nuove autorizzazioni:
```
sudo cyberwatch restart
```
Durante la configurazione dell’isolamento, questo passaggio non è necessario: il comando cyberwatch configure della procedura applica le nuove autorizzazioni.

Prima di aggiornare un’istanza isolata da Cyberwatch 5.31 alla versione 5.32 o a una versione successiva, manualmente o automaticamente, aggiungere 101 ai valori di CBW_NGINX_UID e CBW_NGINX_GID del file /etc/cyberwatch/config.env. Cyberwatch 5.31 funziona anche con questi valori, che vengono applicati al riavvio dell’aggiornamento.

Troubleshooting

I problemi che possono derivare dall’attivazione di userns-remap sono generalmente legati ai diritti sui volumi.

Se, dopo l’attivazione di userns-remap su un’istanza già installata, l’applicazione si avvia senza i propri dati, significa che sono stati creati nuovi volumi: ripristinare il backup eseguito prima dell’isolamento (vedere la sezione «Isolamento di un’istanza con volumi esistenti»).

Può essere utile consultare i log del container del database per escludere eventuali problemi di autorizzazioni:

sudo cyberwatch logs db

A partire da Cyberwatch 5.31, se il container nginx non si avvia o se l’interfaccia HTTPS non è disponibile dopo l’attivazione di userns-remap o dopo un aggiornamento, verificare la configurazione di CBW_NGINX_UID e CBW_NGINX_GID (vedere la sezione Directory dei certificati nginx). I log del container nginx sono utili per la diagnosi:

sudo cyberwatch logs nginx

Un errore Permission denied sul file /etc/nginx/ssl/nginx.crt indica valori non corretti.