Schützen von SQL Server Linux-Containern

Gilt für:SQL Server unter Linux

SQL Server 2017 (14.x)-Container werden standardmäßig als Stammbenutzer gestartet, was zu Sicherheitsbedenken führen kann. In diesem Artikel werden die Sicherheitsoptionen beschrieben, die beim Ausführen von SQL Server Linux-Containern verfügbar sind, und wie Sie einen SQL Server-Container als Nicht-Root-Benutzer erstellen.

In den Beispielen in diesem Artikel wird davon ausgegangen, dass Sie Docker verwenden, aber Sie können dieselben Prinzipien auf andere Containerorchestrierungstools anwenden, einschließlich Kubernetes.

Erstellen und Ausführen von SQL Server 2017-Containern ohne Root-Berechtigung

Führen Sie die folgenden Schritte aus, um einen SQL Server 2017 (14.x)-Container zu erstellen, der als mssql-Nicht-Root-Benutzer gestartet wird.

1. Laden Sie das Beispiel-Dockerfile für SQL Server-Container ohne Root-Berechtigung herunter, und speichern Sie es als Dockerfile.

2. Führen Sie folgenden Befehl im Verzeichnis aus, das die Dockerfile enthält, um den nicht-rootbasierten SQL Server-Container zu erstellen:

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

3. Starten Sie den Container.

   Important

   Die Umgebungsvariable SA_PASSWORD ist veraltet. Verwenden Sie stattdessen 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

   Um Speicherabbilder für die Problembehandlung zu erzeugen, wird das --cap-add SYS_PTRACE-Flag für SQL Server-Container ohne Root-Rechte benötigt.

4. Überprüfen Sie, ob der Container als Benutzer ohne Root-Rechte ausgeführt wird:

   docker exec -it sql1 bash
   

   Führen Sie whoami aus, um den Benutzer anzuzeigen, der innerhalb des Containers aktiv ist.

   whoami
   

Ausführen eines Containers als anderer Nicht-Root-Benutzer auf dem Host

Um den SQL Server-Container als anderer Nicht-Root-Benutzer auszuführen, fügen Sie dem -u-Befehl das docker run-Flag hinzu. Der Container ohne Root-Berechtigung hat die Einschränkung, dass er als Teil der root-Gruppe ausgeführt werden muss, es sei denn, es wird ein Volume für /var/opt/mssql bereitgestellt, auf das der Nicht-Root-Benutzer zugreifen kann. Die root-Gruppe gewährt dem Nicht-Root-Benutzer keine zusätzlichen Root-Berechtigungen.

Ausführen als Benutzer mit einer UID 4000

Sie können SQL Server mit einer benutzerdefinierten UID starten. Der folgende Befehl startet beispielsweise SQL Server mit der 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

Führen Sie den Nicht-Root-Container als Root-Benutzer aus

Du kannst den nicht-rootbezogenen Container bei Bedarf als Root-Benutzer ausführen, was dem Container automatisch alle Dateiberechtigungen gewährt, da er höhere Rechte hat.

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

Ausführen als Benutzer auf Ihrem Hostcomputer

Mit dem folgenden Befehl können Sie SQL Server mit einem vorhandenen Benutzer auf dem Hostcomputer starten:

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

Ausführen als anderer Benutzer und Gruppe

Sie können SQL Server mit einer benutzerdefinierten benutzenden Person oder einer benutzerdefinierten Gruppe starten. In diesem Beispiel verfügt das bereitgestellte Volume über Berechtigungen, die für den Benutzer oder die Gruppe auf dem Hostcomputer konfiguriert sind.

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

Konfigurieren von persistenten Speicherberechtigungen für Container ohne Root-Berechtigung

Damit der Nicht-Root-Benutzer auf Datenbankdateien zugreifen kann, die sich auf eingebundenen Volumes befinden, stelle sicher, dass der Benutzer oder die Gruppe, unter der du den Container ausführst, aus dem persistenten Speicher lesen und in ihn schreiben kann.

Mit diesem Befehl können Sie den aktuellen Besitzer der Datenbankdateien ermitteln.

ls -ll <database file dir>

Führen Sie einen der folgenden Befehle aus, wenn SQL Server keinen Zugriff auf persistierte Datenbankdateien hat.

Zuweisen von Root-Gruppenzugriffsberechtigungen zum Lesen und Schreiben von Datenbankdateien

Erteilen Sie die Root-Gruppenberechtigungen für die folgenden Verzeichnisse, damit der SQL Server-Container ohne Root-Berechtigungen Zugriff auf Datenbankdateien hat.

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

Festlegen des Nicht-Root-Benutzers als Besitzer der Dateien

Der Besitzer kann der festgelegte Nicht-Root-Benutzer oder ein anderer Nicht-Root-Benutzer sein, den Sie angeben möchten. In diesem Beispiel legen Sie die UID 10001 als Nicht-Stammbenutzer fest.

chown -R 10001:0 <database file dir>

Verschlüsseln von Verbindungen mit SQL Server Linux-Containern

Zum Verschlüsseln von Verbindungen mit SQL Server Linux-Containern benötigen Sie ein Zertifikat mit den folgenden Anforderungen.

Das folgende Beispiel zeigt, wie die Verbindungen mit SQL Server für Linux-Containern verschlüsselt werden können. Hier verwenden Sie ein selbstsigniertes Zertifikat, das nicht für Produktionsszenarien verwendet werden sollte. Für solche Umgebungen sollten Sie stattdessen CA-Zertifikate verwenden.

1. Erstellen Sie ein ausschließlich für Test- und Nichtproduktionsumgebungen geeignetes selbstsigniertes Zertifikat.

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

   Im vorherigen Codebeispiel ist der Hostname des SQL-Containers sql1, sodass beim Herstellen einer Verbindung mit diesem Container der in der Verbindungszeichenfolge verwendete Name sql1.contoso.com,5434 lautet. Sie müssen auch sicherstellen, dass der Ordnerpfad /container/sql1/ bereits vorhanden ist, bevor Sie den vorherigen Befehl ausführen.

2. Stellen Sie sicher, dass Sie die richtigen Berechtigungen für die mssql.key und-Dateien mssql.pem festlegen, damit Sie Fehler vermeiden, wenn Sie die Dateien in den SQL Server-Container mounten:

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

3. Erstellen Sie nun eine mssql.conf Datei mit folgendem Inhalt, um die serverinitiierte Verschlüsselung zu ermöglichen. Für die vom Client initiierte Verschlüsselung ändere die letzte Zeile zu forceencryption = 0.

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

   Note

   Bei einigen Linux-Distributionen kann der Pfad zum Speichern des Zertifikats und des Schlüssels ebenfalls /etc/pki/tls/certs/ bzw /etc/pki/tls/private/ . sein. Überprüfen Sie den Pfad, bevor Sie die mssql.conf für SQL Server-Container aktualisieren. Der Speicherort, den Sie im mssql.conf Container festgelegt haben, ist der Speicherort, an dem SQL Server im Container nach dem Zertifikat und seinem Schlüssel sucht. In diesem Fall ist der Speicherort /etc/ssl/certs/ und /etc/ssl/private/.

   Die Datei mssql.conf wird ebenfalls im selben Ordner unter /container/sql1/ erstellt. Nachdem Sie die obigen Schritte ausgeführt haben, sollten Sie über die drei Dateien mssql.conf, mssql.key und mssql.pem im Ordner sql1 verfügen.

4. Stellen Sie den SQL Server-Container mit dem folgenden Befehl bereit (ersetzen Sie <password> es durch ein gültiges Kennwort):

   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
   

   Im vorherigen Befehl hast du die mssql.conf, mssql.pem, und-Dateien mssql.key auf den Container montiert und den SQL Server-Standardport 1433 im Container auf Port 5434 auf dem Host zugeordnet.

   Note

   Wenn Sie Red Hat Enterprise Linux ab Version 8 verwenden, können Sie auch den podman run-Befehl anstelle von docker run verwenden.

Befolgen Sie die Abschnitte "Zertifikat auf Ihrem Client-Rechner registrieren" und "Beispiel-Verbindungsstrings", die in Client Initiated Encryption dokumentiert sind, um Verbindungen zu SQL Server für Linux-Containern zu verschlüsseln.

Verwandte Inhalte

• Bereitstellen und Verbinden mit SQL Server Linux-Containern

• Konfigurieren und Anpassen von SQL Server-Linux-Containern

• Problembehandlung von SQL Server-Docker-Containern