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

Modificare il file /etc/subuid:
```
cyberwatch:231072:65536
cyberwatch:1001:1
```
La prima riga consente di definire la mappatura degli ID di utenti e gruppi in uno user namespace. Questa riga viene generalmente aggiunta in automatico dal sistema al momento della creazione dell’utente, ma alcuni sistemi non lo fanno automaticamente (ad esempio alcune versioni di CentOS).
Ad esempio, cyberwatch:231072:65536 significa che l’utente cyberwatch può utilizzare 65536 ID utente a partire dall’ID 231072.
La riga cyberwatch:1001:1 fa sì che i file creati da root appartengano all’utente con ID 1001 (da sostituire con l’ID dell’utente cyberwatch).

Modificare il file /etc/subgid:

cyberwatch:231072:65536
cyberwatch:1001:1

Riavviare il server affinché le modifiche vengano applicate:
```
sudo reboot
```

Configurare Docker per attivare l’opzione userns-remap:

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

Riavviare Docker:
```
systemctl restart docker
```

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.

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.
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 root (UID e GID 0) e ne limita l’accesso al solo proprietario.

Con userns-remap, l’UID 0 dell’host non corrisponde a root all’interno dei 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 a root nei 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/165536.165536: root nei container corrisponde quindi all’UID 165536 e al GID 165536 sull’host.
Inserire questi valori nel file /etc/cyberwatch/config.env:
```
CBW_NGINX_UID=165536
CBW_NGINX_GID=165536
```
Riavviare Cyberwatch per applicare le nuove autorizzazioni:
```
sudo cyberwatch restart
```

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, verificare la configurazione di CBW_NGINX_UID e CBW_NGINX_GID (vedere la sezione Directory dei certificati nginx riportata sopra). I log del container nginx sono utili per la diagnosi:

sudo cyberwatch logs nginx