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

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

In diesem Artikel wird erläutert, wie Sie externe Daten mithilfe von PolyBase im 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 Anmeldeinformationen bezeichnet, muss der Benutzer die access key id Anmeldeinformationen und secret key id in SQL Server speichern, es liegt an dem Benutzer, die Anmeldeinformationen bei Bedarf explizit zu widerrufen und zu drehen. Eine feinkörnige Zugriffssteuerung würde erfordern, dass der Administrator statische Anmeldeinformationen für jede Anmeldung einrichtet, dieser Ansatz kann beim Umgang mit Dutzenden oder Hunderten eindeutiger Anmeldeinformationen 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 Anmeldeinformationen 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:

  • Installieren Sie das PolyBase-Feature für SQL Server.
  • Installieren Sie SQL Server Management Studio (SSMS) oder Azure Data Studio.
  • S3-kompatibler Speicher.
  • Ein S3-Bucket wird erstellt. Von SQL Server aus können keine Buckets erstellt oder konfiguriert werden.
  • Ein Benutzer (Access Key ID) und der geheime Schlüssel (Secret Key ID), der Ihnen bekannt ist. Sie benötigen beide für die Authentifizierung beim S3-Objektspeicher.
  • ListBucket-Berechtigung für S3-Benutzer zum Durchsuchen.
  • ReadOnly-Berechtigung für S3-Benutzer zum Lesen.
  • WriteOnly-Berechtigung für S3-Benutzer zum Schreiben.
  • Transport Layer Security (TLS) muss 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. Weitere Informationen zu TLS und Zertifikaten finden Sie unter Aktivieren von verschlüsselten Verbindungen mit dem Datenbank-Engine.

Berechtigungen

Damit der Proxybenutzer den Inhalt eines S3-Buckets lesen kann, muss der Benutzer die folgenden Aktionen für den S3-Endpunkt ausführen dürfen:

  • Erstellen Sie in AWS S3 eine benutzerdefinierte Rolle und geben Sie speziell an, welche S3-API Zugriff benötigt.
    • Sicherung erfordert folgende Berechtigungen: ListBucket (Browse), PutObject (Write - for backup).
    • Die Wiederherstellung erfordert folgende Berechtigungen: ListBucket (Browse), GetObject (Read - for restore), GetObject (Read - for restore).
  • In einem anderen S3-kompatiblen Speicher:
    • Für die Sicherung muss der Benutzer (Access Key ID) sowohl über ListBucket- als auch über WriteOnly-Berechtigungen verfügen.
    • Für die Wiederherstellung muss der Benutzer (Access Key ID) sowohl über ListBucket- als auch über ReadOnly-Berechtigungen verfügen.

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 Datenbank mit Anmeldeinformationen s3-dc im Bereich der database_name Datenbank in einer 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;

Einschränkungen der Standardauthentifizierung

  1. Für den S3-kompatiblen Objektspeicher dürfen Kunden ihre Zugriffstasten-ID nicht mit einem : Zeichen erstellen.
  2. 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.
  3. Der SQL-Anmeldeinformationsname ist auf 128 Zeichen im UTF-16-Format beschränkt.
  4. Der erstellte Anmeldeinformationsname muss den Bucketnamen enthalten, es sei denn, diese Anmeldeinformation ist für eine neue externe Datenquelle vorgesehen.
  5. Zugriffstasten-ID und „Geheimer Schlüssel“-ID dürfen nur alphanumerische Werte enthalten.

Pass-Through-Autorisierung (STS)

S3-kompatibler Objektspeicher verfügt über die Möglichkeit, temporäre Anmeldeinformationen über die Verwendung von Secure Token Service (STS) zuzuweisen. Diese Anmeldeinformationen werden kurzfristig und dynamisch generiert.

Die Pass-Through-Autorisierung basiert auf active Directory-Verbunddienst (ADFS), der als OpenID-Verbinden (OIDC)-Identitätsanbieter fungiert, es liegt an 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 Hostserver konfiguriert werden. Es wird davon ausgegangen, dass alle Verbindungen sicher über HTTPS und 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 eine datenbankbezogene Anmeldeinformationen, an die die Identität an den S3-kompatiblen Objektspeicher übergeben wird. Weitere Informationen finden Sie unter CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL). Im folgenden 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_OPTIONSals 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). Im folgenden 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 options specify Windows transport endpoint and relying_party identifier of SQL Server in ADFS.
  • STS options specify S3-compatible object storage STS endpoint and parameters for AssumeRoleWithWebIdentity request. Dies AssumeRoleWithWebIdentity ist die Methode zum Abrufen der temporären Sicherheitsanmeldeinformationen, 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-Verbunddienst

  • Aktivieren Sie sql Server, um eine Anspruchsanbieter-Vertrauensstellung in Active Directory zu sein.
  • Zulassen der Intranet-Windows-Authentifizierung als AUTHENTIFIZIERUNGsmethoden für ADFS.
  • Aktivieren Sie den Windows-Transportdienstendpunkt in Ihrem Intranet.
  • Aktivieren Sie OIDC-Endpunkte (OpenID Verbinden).
  • Registrieren Sie SQL Server als Vertrauensebene.
    • Geben Sie einen eindeutigen Bezeichner an.
    • 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 häufig 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 to URL für S3-kompatible Objektspeicher verwendet werden.
  • ADFS und SQL Server müssen sich in derselben Vorgehensweise befinden Standard. Der ADFS-Windows-Transportendpunkt sollte aus dem Extranet deaktiviert werden.
  • ADFS sollte denselben AD (Active Directory) wie SQL Server als Anspruchsvertrauensanbieter aufweisen.
  • S3-kompatibler Speicher sollte über STS-Endpunktdienst verfügen, mit dem Clients temporäre Anmeldeinformationen mithilfe von JWT externer Identitäten anfordern können.
  • OPENROWSET- und CETAS-Abfragen (Create External Table as Select) 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 bis zu sieben Tage. Nach sieben Tagen läuft das Ticket des Benutzers ab, daher schlägt pass-through 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.