Proteggere i contenitori Linux di SQL Server

Si applica a: SQL Server - Linux

I contenitori di SQL Server 2017 (14.x) vengono avviati come utente ROOT per impostazione predefinita, causando alcuni problemi di sicurezza. Questo articolo illustra le opzioni di sicurezza disponibili quando si eseguono contenitori Linux di SQL Server e come creare un contenitore di SQL Server come utente non root.

Gli esempi in questo articolo ipotizzano che si usi Docker, ma è possibile applicare gli stessi principi ad altri strumenti di orchestrazione dei contenitori, tra cui Kubernetes.

Compilare ed eseguire contenitori di SQL Server 2017 non root

Eseguire la procedura seguente per creare un contenitore di SQL Server 2017 (14.x) che si avvia come utente mssql (non root).

1. Scaricare il dockerfile di esempio per il contenitore di SQL Server non root e salvarlo come dockerfile.

2. Eseguire il comando seguente nel contesto della directory dockerfile per compilare il contenitore di SQL Server non radice:

   cd <path to dockerfile>
   docker build -t 2017-latest-non-root .
   

3. Avviare il contenitore.

   Importante

   La variabile di ambiente SA_PASSWORD è deprecata. Utilizzare invece MSSQL_SA_PASSWORD.

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword@" --cap-add SYS_PTRACE --name sql1 -p 1433:1433 -d 2017-latest-non-root
   

   Nota

   Il flag --cap-add SYS_PTRACE è necessario per i contenitori di SQL Server non radice per generare dump a scopo di risoluzione dei problemi.

4. Verificare che il contenitore sia in esecuzione come utente non radice:

   docker exec -it sql1 bash
   

   Eseguire whoami, che restituirà l'utente in esecuzione nel contenitore.

   whoami
   

Eseguire il contenitore come un altro utente non root nell'host

Per eseguire il contenitore di SQL Server come un altro utente non root, aggiungere il flag -u al comando docker run. Il contenitore non root prevede una restrizione, ovvero deve essere eseguito nell’ambito del gruppo root, a meno che non venga montato un volume in /var/opt/mssql a cui l'utente non root può accedere. Il gruppo root non concede alcuna autorizzazione root aggiuntiva all'utente non root.

Eseguire come utente con UID 4000

È possibile avviare SQL Server con un UID personalizzato. Ad esempio, il comando seguente avvia SQL Server con l'UID 4000:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u 4000:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Eseguire il contenitore non radice come utente radice

Se necessario, è possibile eseguire il contenitore non root come utente root, il che concede anche tutte le autorizzazioni di file automaticamente al contenitore perché ha privilegi più elevati.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" -u 0:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Eseguire come utente nel computer host

È possibile avviare SQL Server con un utente esistente nel computer host con il comando seguente:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u $(id -u myusername):0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Eseguire come utente e gruppo diversi

È possibile avviare SQL Server con un utente e un gruppo personalizzati. In questo esempio, il volume montato ha le autorizzazioni configurate per l'utente o il gruppo nel computer host.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u $(id -u myusername):$(id -g myusername) -v /path/to/mssql:/var/opt/mssql -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Configurare le autorizzazioni di archiviazione permanenti per i contenitori non root

Per consentire all'utente non root di accedere ai file di database in volumi montati, accertarsi che l'utente o il gruppo con cui viene eseguito il contenitore possa leggere e scrivere nell'archivio file permanente.

È possibile ottenere la proprietà corrente dei file di database con questo comando.

ls -ll <database file dir>

Se SQL Server non ha accesso ai file di database persistenti, eseguire uno dei comandi seguenti.

Concedere al gruppo root l'accesso in lettura/scrittura ai file di database

Concedere le autorizzazioni per il gruppo radice alle directory seguenti in modo che il contenitore di SQL Server non radice abbia accesso ai file di database.

chgrp -R 0 <database file dir>
chmod -R g=u <database file dir>

Impostare l'utente non root come proprietario dei file

Può trattarsi dell'utente non root predefinito o di qualsiasi altro utente non root che si vuole specificare. In questo esempio si imposta UID 10001 come utente non radice.

chown -R 10001:0 <database file dir>

Crittografare le connessioni ai contenitori Linux di SQL Server

Per crittografare le connessioni ai contenitori Linux di SQL Server, è necessario un certificato con i requisiti seguenti.

Nel seguito è riportato un esempio di come è possibile crittografare la connessione a contenitori Linux di SQL Server. Qui si utilizza un certificato autofirmato che non deve essere usato per gli scenari di produzione. Per questi ambienti, usare invece i certificati della CA.

1. Creare un certificato autofirmato, adatto solo per ambienti di test e non di produzione.

   openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=sql1.contoso.com' -keyout /container/sql1/mssql.key -out /container/sql1/mssql.pem -days 365
   

   Nell’esempio di codice precedente, sql1 è il nome host del contenitore SQL, quindi quando ci si connette a questo contenitore il nome usato nella stringa di connessione sarà sql1.contoso.com,port. Accertarsi anche che il percorso della cartella /container/sql1/ esista già prima di eseguire il comando precedente.

2. Assicurarsi di impostare le autorizzazioni corrette per i file mssql.key e mssql.pem, in modo da evitare errori quando si montano i file nel contenitore SQL:

   chmod 440 /container/sql1/mssql.pem
   chmod 440 /container/sql1/mssql.key
   

3. Creare ora un file mssql.conf con il contenuto seguente per abilitare la crittografia avviata dal server. Per la crittografia avviata dal client, modificare l'ultima riga in forceencryption = 0.

   [network]
   tlscert = /etc/ssl/certs/mssql.pem
   tlskey = /etc/ssl/private/mssql.key
   tlsprotocols = 1.2
   forceencryption = 1
   

   Nota

   Per alcune distribuzioni di Linux il percorso per l'archiviazione del certificato e della chiave può anche essere rispettivamente /etc/pki/tls/certs/ e /etc/pki/tls/private/. Verificare il percorso prima di aggiornare mssql.conf per i contenitori SQL Server. Il percorso impostato in mssql.conf sarà il percorso in cui SQL Server nel contenitore cercherà il certificato e la relativa chiave. In questo caso, la posizione è /etc/ssl/certs/ e /etc/ssl/private/.

   Viene anche creato il file mssql.conf nello stesso percorso della cartella /container/sql1/. Al termine dell'esecuzione dei passaggi precedenti, i tre file mssql.conf, mssql.key e mssql.pem dovrebbero essere presenti nella cartella sql1.

4. Implementare il contenitore SQL Server con il comando seguente:

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=P@ssw0rd" -p 5434:1433 --name sql1 -h sql1 -v /container/sql1/mssql.conf:/var/opt/mssql/mssql.conf -v   /container/sql1/mssql.pem:/etc/ssl/certs/mssql.pem -v /container/sql1/mssql.key:/etc/ssl/private/mssql.key -d mcr.microsoft.com/mssql/server:2019-latest
   

   Nel comando precedente, sono stati montati i file mssql.conf, mssql.pem e mssql.key nel contenitore ed è stato eseguito il mapping della porta 1433 (porta predefinita di SQL Server) nel contenitore alla porta 5434 dell'host.

   Nota

   Se si usano RHEL 8 e versioni successive, è anche possibile usare il comando podman run anziché docker run.

Vedere le sezioni "Registrare il certificato nel computer client" ed "Esempi di stringhe di connessione" documentate in Crittografia avviata dal client per iniziare a crittografare le connessioni ai contenitori di SQL Server in Linux.

Contenuto correlato

• Distribuire e connettersi a contenitori Docker di SQL Server

• Vedere altre informazioni sulla configurazione e la personalizzazione dei contenitori Docker

• Risoluzione dei problemi dei contenitori Docker di SQL Server