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 seguente comando nella directory del dockerfile per costruire il contenitore SQL Server senza root:

   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=<password>" --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 venga eseguito come utente non root.

   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.

Esegui 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=<password>" --cap-add SYS_PTRACE -u 4000:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Eseguire il container non-root come utente root

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=<password>" -u 0:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Esegui come utente sulla macchina 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=<password>" --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=<password>" --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 che si trovano in volumi montati, assicurarsi che l'utente o il gruppo sotto il quale si esegue il contenitore possa leggere e scrivere nell'archiviazione dei file persistenti.

È 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 al gruppo root per le directory seguenti in modo che il contenitore SQL Server senza privilegi di root 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

Il proprietario può essere l'utente non radice predefinito o qualsiasi altro utente non radice 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. In questo caso si usa 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. È anche necessario assicurarsi che il percorso /container/sql1/ della cartella 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 mssql.conf file 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 potrebbe anche essere /etc/pki/tls/certs/ e /etc/pki/tls/private/ rispettivamente. Verificare il percorso prima di aggiornare il mssql.conf per i contenitori di SQL Server. Il percorso impostato in mssql.conf è 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. Distribuire il contenitore di SQL Server con il comando seguente (sostituire <password> con una password valida):

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" -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, hai montato i file mssql.conf, mssql.pem e mssql.key nel contenitore e hai mappato la porta 1433 (porta predefinita di SQL Server) nel contenitore alla porta 5434 sull'host.

   Nota

   Se si usa Red Hat Enterprise Linux 8 e versioni successive, è anche possibile usare il podman run comando 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 Linux di SQL Server

• Configurare e personalizzare contenitori Linux di SQL Server

• Risoluzione dei problemi dei contenitori Docker di SQL Server