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).

Remarque

Les conteneurs SQL Server 2019 (15.x) et versions ultérieures démarrent automatiquement avec un compte non racine, contrairement aux conteneurs SQL Server 2017 (14.x) qui démarrent par défaut en tant qu’utilisateur racine. Pour plus d'informations sur l'exécution de conteneurs SQL Server en tant que non-root, consultez Sécuriser les conteneurs SQL Server Linux.

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 contexte du répertoire de fichier Dockerfile pour générer le conteneur SQL Server non racine :

   cd <path to dockerfile>
   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
   

   Remarque

   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 racine :

   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

Avertissement

Vérifiez que le conteneur SQL Server a un utilisateur nommé tel que mssql ou root, sinon sqlcmd ne peut pas s’exécuter dans le conteneur. Vous pouvez vérifier si le conteneur SQL Server s’exécute en tant qu’utilisateur nommé en exécutant whoami dans le conteneur.

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

Vous pouvez si nécessaire exécuter le conteneur non racine en tant qu’utilisateur racine. Cette action a également pour effet d’accorder automatiquement toutes les autorisations de fichier au conteneur, car il dispose de 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 racine d’accéder aux fichiers de base de données qui se trouvent 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 de fichiers persistant.

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

Important

Lorsque vous configurez des options d’authentification ou de chiffrement Active Directory, telles que Transparent Data Encryption (TDE) et SSL/TLS pour SQL Server sur Linux ou conteneurs, il existe plusieurs fichiers, tels que le keytab, les certificats et la clé de machine, créés par défaut sous le dossier/var/opt/mssql/secrets, et l’accès auquel il est limité par défaut aux utilisateurs et mssql aux root utilisateurs. Lorsque vous configurez le stockage persistant pour les conteneurs SQL Server, utilisez la même stratégie d’accès, en veillant à ce que le chemin d’accès sur l’hôte ou le volume partagé mappé au /var/opt/mssql/secrets dossier à l’intérieur du conteneur soit protégé et accessible uniquement aux mssql utilisateurs de root l’hôte. Si l’accès à ce chemin/dossier est compromis, un utilisateur malveillant peut accéder à ces fichiers critiques, compromettant alors la hiérarchie de chiffrement et/ou les configurations Active Directory.

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,port. 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. Veillez à définir les autorisations appropriées sur les fichiers mssql.key et mssql.pem, afin d’éviter des 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 lancé par le client, remplacez la dernière ligne par forceencryption = 0.

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

   Remarque

   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 avez monté les fichiers mssql.confmssql.pem et les mssql.keyfichiers sur le conteneur et mappé le port 1433 (port par défaut SQL Server) dans le conteneur au port 5434 sur l’hôte.

   Remarque

   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 « Inscription du certificat sur une machine cliente » et « Exemples de chaînes de connexion » documentées dans Chiffrement à l’initiative du client pour commencer le chiffrement des connexions à SQL Server sur des conteneurs SQL Server sur Linux.

Contenu connexe

• Commencez avec les images conteneur SQL Server 2025 (17.x) sur Docker en suivant le guide de démarrage rapide

• Déployer et se connecter à des conteneurs Linux SQL Server

• Configurer et personnaliser les conteneurs Linux de SQL Server

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