Konfigurieren von PolyBase für den Zugriff auf externe Daten im S3-kompatiblen Objektspeicher

  • Artikel

Gilt für: SQL Server 2022 (16.x)

In diesem Artikel wird erläutert, wie Sie mithilfe von PolyBase externe Daten in S3-kompatiblen Objektspeicher abfragen.

SQL Server 2022 (16.x) bietet die Möglichkeit, eine Verbindung mit einem S3-kompatiblen Objektspeicher herzustellen. Es gibt zwei verfügbare Optionen für die Authentifizierung: Standardauthentifizierung oder Pass-Through-Autorisierung (auch als STS-Autorisierung bezeichnet).

Für die Standardauthentifizierung, auch als statische Anmeldedaten bezeichnet, muss der Benutzer access key id und secret key id in SQL Server speichern. Es liegt in der Verantwortung des Benutzers, die Anmeldedaten bei Bedarf explizit zu widerrufen und zu ändern. Eine differenzierte Access Control würde erfordern, dass der Administrator statische Anmeldedaten für jede Anmeldung einrichtet. Dieser Ansatz kann beim Umgang mit Dutzenden oder Hunderten eindeutiger Anmeldedaten schwierig sein.

Die Pass-Through-Autorisierung (STS) bietet eine Lösung für diese Probleme, indem die Verwendung von SQL Server-Identitäten des eigenen Benutzers für den Zugriff auf den S3-kompatiblen Objektspeicher ermöglicht wird. S3-kompatibler Objektspeicher verfügt über die Möglichkeit, temporäre Anmeldedaten mithilfe des Secure Token Service (STS) zuzuweisen. Diese Anmeldeinformationen werden kurzfristig und dynamisch generiert.

Dieser Artikel enthält Anweisungen für die Standardauthentifizierung und die Pass-Through-Autorisierung (Pass-Through Authorization, STS).

Voraussetzungen

Um die S3-kompatiblen Objektspeicherintegrationsfeatures zu verwenden, benötigen Sie die folgenden Tools und Ressourcen:

Berechtigungen

Damit Proxybenutzer*innen den Inhalt eines S3-Buckets lesen können, müssen Benutzer*innen (Access Key ID) die folgenden Aktionen für den S3-Endpunkt ausführen dürfen:

  • GetBucketLocation- und GetObject-Berechtigungen sind erforderlich, um eine bestimmte Datei aus dem S3-Objektspeicher zu lesen.
    • ListBucket ist für externe Tabellen oder OPENROWSET-Abfragen erforderlich, die auf einen S3-Ordnerspeicherort statt auf eine einzelne Datei verweisen. Ohne ListBucket-Berechtigungen wird die Fehlermeldung Msg 4860, Level 16, State 7, Line 15 Cannot bulk load. The file "s3://<ip address>:9000/bucket/*.*" does not exist or you don't have file access rights. angezeigt
  • Die PutObject-Berechtigung ist erforderlich, um in den S3-Objektspeicher zu schreiben.

Tipp

Ihr S3-kompatibler Objektspeicheranbieter benötigt möglicherweise zusätzliche API-Vorgangsberechtigungen. Oder Sie verwenden eine andere Benennung für Rollen, die Berechtigungen für API-Vorgänge enthalten. Informationen dazu finden Sie in der Dokumentation des Produktes.

Aktivieren von PolyBase

  1. Aktivieren von PolyBase in sp_configure:

    EXEC sp_configure @configname = 'polybase enabled', @configvalue = 1;
GO
RECONFIGURE
GO

  2. Bestätigen Sie die Einstellung:

    EXEC sp_configure @configname = 'polybase enabled';

Authentifizierung

Um fortzufahren, wählen Sie die Standardauthentifizierung oder Pass-Through-Autorisierung (STS) aus.

Standardauthentifizierung

Vor dem Erstellen von datenbankweit gültigen Anmeldeinformationen muss die Benutzerdatenbank über einen Hauptschlüssel zum Schützen der Anmeldeinformationen verfügen. Weitere Informationen finden Sie unter CREATE MASTER KEY.

Erstellen von Anmeldeinformationen mit Datenbankbereich mit Standardauthentifizierung

Das folgende Beispielskript erstellt eine datenbankbezogene Anmeldeinformation s3-dc in der database_name-Datenbank in SQL Server-Instanz. Weitere Informationen finden Sie unter CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL).

USE [database_name];
GO
IF NOT EXISTS(SELECT * FROM sys.database_scoped_credentials WHERE name = 's3_dc')
BEGIN
 CREATE DATABASE SCOPED CREDENTIAL s3_dc
 WITH IDENTITY = 'S3 Access Key',
 SECRET = '<AccessKeyID>:<SecretKeyID>' ;
END
GO

Überprüfen Sie die neue datenbankbezogene Anmeldeinformation mit sys.database_scoped_credentials (Transact-SQL):

SELECT * FROM sys.database_scoped_credentials;

Erstellen einer externen Datenquelle mit Standardauthentifizierung

Das folgende Beispielskript erstellt eine externe Datenquelle s3_ds in der Quellbenutzerdatenbank in SQL Server. Die externe Datenquelle verweist auf die Anmeldeinformationen für die Datenbank s3_dc. Weitere Informationen finden Sie unter CREATE EXTERNAL DATA SOURCE (CREATE EXTERNAL DATA SOURCE).

CREATE EXTERNAL DATA SOURCE s3_ds
WITH
(   LOCATION = 's3://<ip_address>:<port>/'
,   CREDENTIAL = s3_dc
);
GO

Überprüfen Sie die neue externe Datenquelle mit sys.external_data_sources.

SELECT * FROM sys.external_data_sources;

Virtuelle gehostete URLs

Einige S3-kompatible Speichersysteme (z. B. Amazon Web Services) verwenden URLs im virtual_hosted-Stil, um die Ordnerstruktur im S3-Bucket zu implementieren. Fügen Sie das folgende CONNECTION_OPTIONS hinzu, um die Erstellung von externen Tabellen zu ermöglichen, die auf Ordner im S3-Bucket verweisen, z. B. CONNECTION_OPTIONS = '{"s3":{"url_style":"virtual_hosted"}}'.

Ohne diese CONNECTION_OPTIONS-Einstellung können Sie beim Abfragen externer Tabellen, die auf einen Ordner verweisen, den folgenden Fehler beobachten:

Msg 13807, Level 16, State 1, Line 23  
Content of directory on path '/<folder_name>/' cannot be listed.

Einschränkungen der Standardauthentifizierung

  • Bei S3-kompatiblem Objektspeicher dürfen Kunden ihre Zugriffsschlüssel-ID nicht mit einem :-Zeichen erstellen.
  • Die Gesamtlänge der URL ist auf 259 Zeichen beschränkt. Dies bedeutet, dass s3://<hostname>/<objectkey> 259 Zeichen nicht überschreiten darf. s3:// wird auf diesen Grenzwert angerechnet, sodass die Pfadlänge 259-5 = 254 Zeichen nicht überschreiten kann.
  • Der SQL-Anmeldeinformationsname ist auf 128 Zeichen im UTF-16-Format beschränkt.
  • Der erstellte Anmeldeinformationsname muss den Bucketnamen enthalten, es sei denn, diese Anmeldeinformation ist für eine neue externe Datenquelle vorgesehen.
  • Zugriffstasten-ID und „Geheimer Schlüssel“-ID dürfen nur alphanumerische Werte enthalten.

Pass-Through-Autorisierung (STS)

Ein S3-kompatibler Objektspeicher hat die Möglichkeit, mit Hilfe des Secure Token Service (STS) einen temporären Berechtigungsnachweis zu vergeben. Diese Anmeldeinformationen werden kurzfristig und dynamisch generiert.

Die Pass-Through-Autorisierung basiert auf Active Directory-Verbunddienste (ADFS), der als OpenID Connect (OIDC)-Identitätsanbieter fungiert. Es liegt in der Verantwortung der ADFS, mit dem S3-kompatiblen Objektspeicher-STS zu kommunizieren, den STS anzufordern und zurück an SQL Server bereitzustellen.

Verwenden der Pass-Through-Autorisierung (STS) auf SQL Server

  1. TLS muss mit Zertifikaten zwischen SQL Server und dem S3-kompatiblen Host-Server konfiguriert werden. Es wird vorausgesetzt, dass alle Verbindungen sicher über HTTPS (nicht über HTTP) übertragen werden. Der Endpunkt wird anhand eines Zertifikats überprüft, das auf dem SQL Server-Betriebssystemhost installiert ist. Öffentliche oder selbstsignierte Zertifikate werden unterstützt.

  2. Erstellen Sie datenbankbezogene Anmeldedaten, an die die Identität an den S3-kompatiblen Objektspeicher übergeben wird. Weitere Informationen finden Sie unter CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL). So wie folgendes Beispiel:

    CREATE DATABASE SCOPED CREDENTIAL CredName
WITH IDENTITY = 'User Identity'

  3. Erstellen Sie eine externe Datenquelle, um auf den S3-kompatiblen Objektspeicher zuzugreifen. Verwenden Sie CONNECTION_OPTIONS als JSON-Format, um die erforderlichen Informationen sowohl für die ADFS als auch für STS zu informieren. Weitere Informationen finden Sie unter CREATE EXTERNAL DATA SOURCE (CREATE EXTERNAL DATA SOURCE). So wie folgendes Beispiel:

    CREATE EXTERNAL DATA SOURCE EdsName
WITH
{
    LOCATION = 's3://<hostname>:<port>/<bucket_name>'
    , CREDENTIAL = <CredName>
    [ , CONNECTION_OPTIONS = ' {
        [ , "authorization": {
                "adfs": {
                    "endpoint": "http[s]://hostname:port/servicepath",
                    "relying_party": "SQL Server Relying Party Identifier"
                },
                "sts": {
                    "endpoint": "http[s]://hostname:port/stspath",
                    "role_arn": "Role Arn"
                    [ , "role_session_name": "AD user login" ] -- default value if not provided
                    [ , "duration_seconds": 3600 ]             -- default value if not provided
                    [ , "version": "2011-06-15" ]              -- default value if not provided
                    [ , "request_parameters": "In request query string format" ]
                }
            } ]
        [ , "s3": {
            "url_style": "Path"
            } ]
    }' ]
}
  • ADFS-Optionen geben den Windows-Datentransport-Endpunkt und den Bezeichner relying_party von SQL Server in ADFS an.
  • STS-Optionen geben einen S3-kompatiblen Objektspeicher-STS-Endpunkt und Parameter für die Anfrage AssumeRoleWithWebIdentity an. AssumeRoleWithWebIdentity ist die Methode zum Abrufen der temporären Sicherheitsanmeldedaten, die zur Authentifizierung verwendet werden. Die vollständige Liste der Parameter, einschließlich optionaler Parameter und Informationen zu Standardwerten, finden Sie in der STS-API-Referenz.

Verwenden der Pass-Through-Autorisierung (STS) mit Active Directory

  • Markieren Sie die EIGENSCHAFTEN von SQL Server-Benutzerkonten in AD als nicht empfindlich, um Pass-Through an S3-kompatiblen Speicher zu ermöglichen.
  • Zulassen der eingeschränkten Kerberos-Delegierung an ADFS-Dienste für den Benutzer im Zusammenhang mit SQL Server SPN (Dienstprinzipalnamen).

Verwenden der Pass-Through-Autorisierung (STS) mit dem Active Directory-Verbunddienste (AD FS)

  • Aktivieren Sie SQL Server für Vertrauen für Anspruchsanbieter in Active Directory.
  • Zulassen der Intranet-Windows-Authentifizierung als Authentifizierungsmethoden für ADFS.
  • Aktivieren Sie den Windows-Datentransport-Dienstendpunkt in Ihrem Intranet.
  • Aktivieren Sie OIDC-Endpunkte (OpenID Connect).
  • Registrieren Sie SQL Server als Vertrauen für die vertrauende Seite.
    • Bereitstellen eines eindeutiger Bezeichners.
    • Legen Sie Anspruchsregeln für JWT (JSON-Webtoken) fest.
  • Benutzerdefinierte Ansprüche – Diese Ansprüche können von Kunden hinzugefügt werden, wenn diese zum Ermitteln der Zugriffsrichtlinie auf der Speicherseite erforderlich sind.
  • Weitere herstellerspezifische Informationen finden Sie bei Ihrem S3-kompatiblen Plattformanbieter.

Verwenden der Pass-Through-Autorisierung (STS) für S3-kompatible Objektspeicher

  • Befolgen Sie die Dokumentation, die vom S3-kompatiblen Speicheranbieter bereitgestellt wird, um einen externen OIDC-Identitätsanbieter einzurichten. Zum Einrichten des Identitätsanbieters werden meist folgende Werte benötigt.

    • Konfigurationsendpunkt des OIDC-Anbieters.
    • Fingerabdruck des OIDC-Anbieters.
    • Pass-Through-Autorisierung zum S3-kompatiblen Objektspeicher

Einschränkungen der Pass-Through-Autorisierung (STS)

  • Pass-Through-Autorisierung (STS) an S3-kompatible Objektspeicher wird für SQL Server-Anmeldungen mit Windows-Authentifizierung unterstützt.
  • STS-Token können nicht für BACKUP an URL für S3-kompatible Objektspeicher verwendet werden.
  • ADFS und SQL Server müssen sich in derselben Domäne befinden. Der ADFS-Windows-Datentransportendpunkt sollte aus dem Extranet deaktiviert werden.
  • ADFS sollte denselben AD (Active Directory) wie SQL Server als Anspruchsvertrauensanbieter aufweisen.
  • S3-kompatibler Speicher sollte über einen STS-Endpunktdienst verfügen, mit dem Clients temporäre Anmeldedaten mithilfe von JWT externer Identitäten anfordern können.
  • OPENROWSET- und CETAS-Abfragen (Externe Tabelle als Auswahl erstellen) werden für das Parkett- und CSV-Format unterstützt.
  • Standardmäßig beträgt die Verlängerungszeit für Kerberos-Tickets sieben Tage und die Lebensdauer beträgt 10 Stunden unter Windows und 2 Stunden unter Linux. SQL Server erneuert das Kerberos-Token des Benutzers für bis zu sieben Tage. Nach sieben Tagen läuft das Ticket des Benutzers ab, daher schlägt Passthrough an S3-kompatiblen Speicher fehl. In diesem Fall muss SQL Server den Benutzer erneut authentifizieren, um ein neues Kerberos-Ticket zu erhalten.
  • ADFS 2019 mit Windows Server 2019 wird unterstützt.
  • S3-REST-API-Aufrufe verwenden AWS-Signaturversion 4.

PolyBase auf SQL Server für Linux

Für PolyBase auf SQL Server für Linux sind mehr Konfigurationen erforderlich.

  • TLS muss konfiguriert sein. Es wird vorausgesetzt, dass alle Verbindungen sicher über HTTPS (nicht über HTTP) übertragen werden. Der Endpunkt wird anhand eines Zertifikats überprüft, das auf dem SQL Server-Betriebssystemhost installiert ist.
  • Die Zertifikatverwaltung unterscheidet sich unter Linux. Überprüfen und befolgen Sie die Konfiguration, die in Linux-Support für S3-kompatiblen Speicher beschrieben ist.

Zugehöriger Inhalt