Sécuriser les conteneurs SQL Server Linux

S’applique à :SQL Server sur Linux

Les conteneurs SQL Server 2017 (14.x) démarrent par défaut en tant qu’utilisateur racine, ce qui peut provoquer des problèmes de sécurité. Cet article décrit les options de sécurité à votre disposition lors de l’exécution de conteneurs SQL Server Linux, puis explique comment créer un conteneur SQL Server en tant qu’utilisateur non racine.

Les exemples de cet article supposent que vous utilisez Docker, mais vous pouvez appliquer les mêmes principes à d’autres outils d’orchestration de conteneurs comme Kubernetes.

Générer et exécuter des conteneurs SQL Server 2017 non-root

Suivez la procédure ci-dessous pour créer un conteneur SQL Server 2017 (14.x) qui démarre en tant qu’utilisateur mssql (non racine).

1. Téléchargez l’exemple de fichier Dockerfile pour les conteneurs SQL Server non racines et enregistrez-le en tant que Dockerfile.

2. Exécutez la commande suivante dans le répertoire contenant le fichier Docker pour construire le conteneur SQL Server non root :

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

3. Démarrez le conteneur.

   Important

   La variable d’environnement SA_PASSWORD est obsolète. Utilisez MSSQL_SA_PASSWORD à la place.

   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

   L’indicateur --cap-add SYS_PTRACE est requis pour les conteneurs SQL Server non-root afin de générer des vidages pour des raisons de dépannage.

4. Vérifiez que le conteneur s’exécute en tant qu’utilisateur non-root :

   docker exec -it sql1 bash
   

   Exécutez whoami pour retourner l’utilisateur qui s’exécute dans le conteneur.

   whoami
   

Exécuter le conteneur comme un autre utilisateur non racine sur l’hôte

Pour exécuter le conteneur SQL Server en tant qu’autre utilisateur non racine, ajoutez l’indicateur -u sur la commande docker run. Le conteneur non racine a comme restriction qu’il doit s’exécuter dans le groupe root, sauf si un volume est monté sur /var/opt/mssql qui est accessible à l’utilisateur non racine. Le groupe root n’accorde pas d’autorisations racines supplémentaires à l’utilisateur non racine.

Exécuter en tant qu’utilisateur avec un UID 4000

Vous pouvez démarrer SQL Server avec un UID personnalisé. Par exemple, la commande suivante démarre SQL Server avec 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

Exécuter le conteneur non racine en tant qu’utilisateur racine

Vous pouvez exécuter le conteneur non-root en tant qu’utilisateur root si nécessaire, ce qui accorde automatiquement tous les droits de fichiers au conteneur, car il a des privilèges plus élevés.

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

Exécuter en tant qu’utilisateur sur votre ordinateur hôte

Vous pouvez démarrer SQL Server avec un utilisateur existant sur l’ordinateur hôte à l’aide de la commande suivante :

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

Exécuter en tant qu’utilisateur ou groupe différent

Vous pouvez démarrer SQL Server avec un utilisateur ou groupe personnalisé. Dans cet exemple, le volume monté dispose des autorisations configurées pour l’utilisateur ou le groupe sur l’ordinateur hôte.

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

Configurer des autorisations de stockage persistant pour les conteneurs non racine

Pour permettre à l’utilisateur non root d’accéder aux fichiers de base de données sur des volumes montés, assurez-vous que l’utilisateur ou le groupe sous lequel vous exécutez le conteneur peut lire et écrire dans le stockage persistant des fichiers.

Vous pouvez obtenir la propriété actuelle des fichiers de base de données à l’aide de cette commande.

ls -ll <database file dir>

Exécutez l’une des commandes suivantes si SQL Server n’a pas accès aux fichiers de base de données persistants.

Accorder au groupe racine un accès en lecture et en écriture aux fichiers de base de données

Accordez au groupe racine des autorisations sur les répertoires suivants afin que le conteneur SQL Server non racine ait accès aux fichiers de base de données.

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

Définir l’utilisateur non-racine comme propriétaire des fichiers

Le propriétaire peut être l’utilisateur non racine par défaut ou tout autre utilisateur non racine que vous souhaitez spécifier. Dans cet exemple, vous définissez UID 10001 comme utilisateur non racine.

chown -R 10001:0 <database file dir>

Chiffrer les connexions aux conteneurs SQL Server Linux

Pour chiffrer les connexions à des conteneurs Linux SQL Server, il vous faut un certificat qui respecte les exigences suivantes.

Voici un exemple de chiffrement de la connexion à des conteneurs Linux SQL Server. Ici, vous utilisez un certificat auto-signé, qui ne doit pas être utilisé pour les scénarios de production. Pour ces environnements, vous devez utiliser à la place des certificats d’autorité de certification.

1. Créez un certificat auto-signé, qui convient seulement aux environnements de test et hors production.

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

   Dans l’exemple de code précédent, sql1 est le nom d’hôte du conteneur SQL : lors de la connexion à ce conteneur, le nom utilisé dans la chaîne de connexion sera donc sql1.contoso.com,5434. Vous devez également vous assurer que le chemin /container/sql1/ du dossier existe déjà avant d’exécuter la commande précédente.

2. Assurez-vous de définir les bonnes permissions sur les mssql.key fichiers etmssql.pem, afin d’éviter les erreurs lors du montage des fichiers sur le conteneur SQL Server :

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

3. Créez maintenant un mssql.conf fichier avec le contenu suivant pour activer le chiffrement initié par le serveur. Pour le chiffrement initié par le client, changez la dernière ligne en forceencryption = 0.

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

   Note

   Pour certaines distributions Linux, le chemin d’accès pour le stockage du certificat et de la clé peut également être /etc/pki/tls/certs/ et /etc/pki/tls/private/ respectivement. Vérifiez le chemin avant de mettre à jour le mssql.conf pour les conteneurs SQL Server. L'emplacement que vous spécifiez dans mssql.conf est celui où SQL Server dans le conteneur va chercher le certificat et sa clé. Dans ce cas, cet emplacement est /etc/ssl/certs/ et /etc/ssl/private/.

   Le fichier mssql.conf est également créé sous le même emplacement de dossier, /container/sql1/. Après avoir effectué les étapes ci-dessus, vous devez avoir les trois fichiers mssql.conf, mssql.key et mssql.pem dans le dossier sql1.

4. Déployez le conteneur SQL Server avec la commande suivante (remplacez <password> par un mot de passe valide) :

   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
   

   Dans la commande précédente, vous montiez les mssql.conffichiers , mssql.pem, et mssql.key dans le conteneur et vous mappiez le port par défaut 1433 de SQL Server dans le conteneur vers le port 5434 de l’hôte.

   Note

   Si vous utilisez Red Hat Enterprise Linux 8 et versions ultérieures, vous pouvez également utiliser podman run la commande au lieu de docker run.

Suivez les sections « Enregistrer le certificat sur votre machine client » et « Exemples de chaînes de connexion » documentées dans le chiffrement initié par le client pour commencer à chiffrer les connexions vers SQL Server sur Linux containers.

Contenu connexe

• Déployer et se connecter aux conteneurs SQL Server Linux

• Configurer et personnaliser les conteneurs Linux de SQL Server

• Résoudre les problèmes liés aux conteneurs Docker SQL Server