Proteggere i contenitori Linux di SQL Server

Si applica a:SQL Server su 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. Esegui il seguente comando nella directory che contiene il Dockerfile per costruire il contenitore SQL Server non root:

   cd <path to Dockerfile directory>
   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
   

   Note

   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. Controlla che il contenitore sia in esecuzione 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

Puoi eseguire il contenitore non root come utente root se necessario, che concede automaticamente tutti i permessi ai file al container, 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 permettere all'utente non root di accedere ai file del database presenti su volumi montati, assicurati che l'utente o il gruppo sotto cui esegui il contenitore possa leggere e scrivere sullo storage persistente dei file.

È 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,5434. È anche necessario assicurarsi che il percorso /container/sql1/ della cartella esista già prima di eseguire il comando precedente.

2. Assicurati di impostare i permessi corretti sui mssql.key file e, mssql.pem così da evitare errori quando monti i file nel container SQL Server:

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

3. Ora crea un mssql.conf file con il seguente contenuto per abilitare la crittografia avviata dal server. Per la crittografia avviata dal cliente, cambiare l'ultima riga in forceencryption = 0.

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

   Note

   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, montavi i mssql.conffile , mssql.pem, e mssql.key sul container e mappavi la porta predefinita 1433 di SQL Server nel container alla porta 5434 dell'host.

   Note

   Se si usa Red Hat Enterprise Linux 8 e versioni successive, è anche possibile usare il podman run comando anziché docker run.

Segui le sezioni "Registra il certificato sulla tua macchina client" e "Esempi stringhe di connessione" documentate in crittografia iniziata dal cliente per iniziare a criptare le connessioni a SQL Server in Linux container.

Contenuti correlati

• Distribuire e connettersi ai contenitori SQL Server per Linux

• Configurare e personalizzare contenitori Linux di SQL Server

• Risoluzione dei problemi dei contenitori Docker di SQL Server