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.
Hinweis
Container für SQL Server 2019 (15.x) oder neuere Versionen werden automatisch als Nicht-Stammcontainer gestartet, während SQL Server 2017-Container (14.x) standardmäßig als Stammcontainer gestartet werden. Weitere Informationen zum Ausführen von SQL Server-Containern als Nichtstammcontainer finden Sie unter Konfigurieren der Sicherheit.
Laden Sie das Beispiel-Dockerfile für SQL Server-Container ohne Root-Berechtigung herunter, und speichern Sie es als
dockerfile
.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 .
Starten Sie den Container.
Wichtig
Die Umgebungsvariable
SA_PASSWORD
ist veraltet. Verwenden Sie stattdessenMSSQL_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.Ü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
Warnung
Stellen Sie sicher, dass der SQL Server-Container einen benannten Benutzer wie mssql
oder root
aufweist. Andernfalls kann sqlcmd nicht innerhalb des Containers ausgeführt werden. Sie können überprüfen, ob der SQL Server-Container als benannter Benutzer ausgeführt wird, indem Sie whoami
innerhalb des Containers ausführen.
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
Wichtig
Beim Konfigurieren von Active Directory-Authentifizierungs- oder Verschlüsselungsoptionen wie Transparent Data Encryption (TDE) und SSL für SQL Server für Linux oder Container gibt es mehrere Dateien, z. B. die Schlüsseltabelle, Zertifikate und Computerschlüssel, die standardmäßig im Ordner /var/opt/mssql/secrets
erstellt werden und auf die standardmäßig nur mssql
- und root
-Benutzer zugreifen dürfen. Verwenden Sie beim Konfigurieren von persistentem Speicher für SQL Server-Container dieselbe Zugriffsstrategie. Dadurch wird sichergestellt, dass der Pfad auf dem Host oder dem freigegebenen Volume dem Ordner /var/opt/mssql/secrets
im Container zugeordnet wird, geschützt ist und auch nur für mssql
- oder root
-Benutzer auf dem Host zugänglich ist. Wenn der Zugriff auf diesen Pfad bzw. Ordner kompromittiert ist, kann ein böswilliger Benutzer Zugriff auf diese kritischen Dateien erhalten, wodurch die Verschlüsselungshierarchie und/oder die Active Directory-Konfigurationen gefährdet werden.
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.
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 Namesql1.contoso.com,port
lautet. Sie müssen auch sicherstellen, dass der Ordnerpfad/container/sql1/
bereits vorhanden ist, bevor Sie den obigen Befehl ausführen.Stellen Sie sicher, dass Sie die richtigen Berechtigungen für die Dateien
mssql.key
undmssql.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
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 inforceencryption = 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 inmssql.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 Dateienmssql.conf
,mssql.key
undmssql.pem
im Ordnersql1
verfügen.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
undmssql.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 vondocker 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
- Der Schnellstart erleichtert Ihnen den Einstieg in die Verwendung von SQL Server 2017-Containerimages (14.x) in Docker.
- Der Schnellstart erleichtert Ihnen den Einstieg in die Verwendung von SQL Server 2019-Containerimages (15.x) in Docker.
- Der Schnellstart vereinfacht Ihnen den Einstieg in die Verwendung von Containerimages in SQL Server 2022 (16.x) in Docker.