Schützen von SQL Server Linux-Containern

Gilt für: SQL Server – 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 Linux verwenden. Sie können dieselben Prinzipien jedoch 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 den folgenden Befehl im Kontext des dockerfile-Verzeichnisses aus, um den SQL Server-Container ohne Root-Berechtigung zu erstellen:

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

3. Starten Sie den Container.

   Wichtig

   Die Umgebungsvariable SA_PASSWORD ist veraltet. Verwenden Sie stattdessen MSSQL_SA_PASSWORD.

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword@" --cap-add SYS_PTRACE --name sql1 -p 1433:1433 -d 2017-latest-non-root
   

   Hinweis

   Das --cap-add SYS_PTRACE-Flag wird für SQL Server-Container ohne Root-Berechtigung benötigt, um Sicherungsdateien für die Problembehandlung zu erzeugen.

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

   docker exec -it sql1 bash
   

   Führen Sie whoami aus, um den Benutzer zurückzugeben, der innerhalb des Containers ausgeführt wird.

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

Ausführen des Containers ohne Root-Berechtigung als Root-Benutzer

Sie können den Nicht-Stammcontainer bei Bedarf als Stammbenutzer ausführen, wodurch dem Container automatisch alle Dateiberechtigungen gewährt werden, da er über höhere Rechte verfügt.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" -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=MyStrongPassword" --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 einem benutzerdefinierten Benutzer 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=MyStrongPassword" --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

Um dem Nicht-Stammbenutzer den Zugriff auf Datenbankdateien zu ermöglichen, die sich auf bereitgestellten Volumes befinden, stellen Sie sicher, dass der Benutzer oder die Gruppe, unter dem oder der Sie den Container ausführen, Lese-/Schreibvorgänge im persistenten Dateispeicher ausführen 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

Dies kann der standardmäßig festgelegte Nicht-Root-Benutzer oder ein anderer Nicht-Root-Benutzer sein, den Sie angeben möchten. In diesem Beispiel haben wir die UID 10001 als Nicht-Root-Benutzer festgelegt.

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 wir 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,port lautet. Sie müssen auch sicherstellen, dass der Ordnerpfad /container/sql1/ bereits vorhanden ist, bevor Sie den obigen Befehl ausführen.

2. Stellen Sie sicher, dass Sie die richtigen Berechtigungen für die Dateien mssql.key und mssql.pem festlegen, um Fehler beim Einbinden der Dateien in den SQL Server-Container zu vermeiden:

   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 aktivieren. Ändern Sie für die clientinitiierte Verschlüsselung die letzte Zeile in forceencryption = 0.

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

   Hinweis

   Bei einigen Linux-Distributionen kann der Pfad zum Speichern des Zertifikats bzw. des Schlüssels auch „/etc/pki/tls/certs/“ bzw. „/etc/pki/tls/private/“ lauten. Überprüfen Sie den Pfad, bevor Sie mssql.conf für SQL Server-Container aktualisieren. Der Speicherort, den Sie in mssql.conf festlegen, ist der, an dem SQL Server im Container nach dem Zertifikat und dessen Schlüssel suchen wird. In diesem Fall entspricht 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:

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=P@ssw0rd" -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
   

   Mir dem vorherigen Befehl haben Sie die Dateien mssql.conf, mssql.pem und mssql.key in den Container eingebunden und den Port 1433 (SQL Server-Standardport) im Container dem Port 5434 auf dem Host zugeordnet.

   Hinweis

   Wenn Sie RHEL 8 oder höher verwenden, können Sie auch den podman run-Befehl anstelle von docker run verwenden.

Befolgen Sie unter Vom Client initiierte Verschlüsselung die Anweisungen in den Abschnitten „Registrieren des Zertifikats auf dem Clientcomputer“ und „Exemplarische Verbindungszeichenfolgen“, um mit der Verschlüsselung von Verbindungen mit SQL Server für Linux-Containern zu beginnen.

Zugehöriger Inhalt

• Bereitstellen von und Herstellen einer Verbindung mit SQL Server Docker-Containern

• Verweisen auf zusätzliche Konfiguration und Anpassung für Docker-Container

• Problembehandlung von SQL Server Docker-Containern