Configurare PolyBase per l'accesso ai dati esterni nelle risorse di archiviazione di oggetti compatibili con S3

  • Articolo

Si applica a: SQL Server 2022 (16.x)

Questo articolo illustra come usare PolyBase per eseguire query sui dati esterni in una risorsa di archiviazione di oggetti compatibile con S3.

SQL Server 2022 (16.x) introduce la possibilità di connettersi a qualsiasi risorsa di archiviazione di oggetti compatibile con S3; sono disponibili due opzioni per l'autenticazione: autenticazione di base o autorizzazione pass-through (nota anche come autorizzazione STS).

L'autenticazione di base, nota anche come credenziali statiche, prevede che l'utente archivi access key id e secret key id in SQL Server; spetta all’utente revocare e ruotare in modo esplicito le credenziali ogni qual volta sia necessario. Il controllo di accesso con granularità fine prevede che l'amministratore configuri le credenziali statiche per ogni accesso; questo approccio può risultare complesso quando si gestiscono decine o centinaia di credenziali univoche.

L'autorizzazione pass-through (STS) offre una soluzione a questi problemi abilitando l'uso delle identità dell'utente di SQL Server per accedere alle risorse di archiviazione oggetti compatibili con S3. Le risorse di archiviazione oggetti compatibili con S3 hanno la possibilità di assegnare credenziali temporanee usando il servizio token di sicurezza (STS). Tali credenziali sono a breve termine e vengono generate in modo dinamico.

Questo articolo include istruzioni per l'autenticazione di base e l'autorizzazione pass-through (autorizzazione STS).

Prerequisiti

Per usare le funzionalità di integrazione delle risorse di archiviazione di oggetti compatibili con S3, sono necessari gli strumenti e le risorse seguenti:

Autorizzazioni

Per consentire all'utente proxy di leggere il contenuto di un bucket S3, l'utente (Access Key ID) deve essere autorizzato a eseguire le azioni seguenti a fronte dell'endpoint S3:

  • Per leggere un file specifico dall'archiviazione oggetti S3 sono necessarie le autorizzazioni GetBucketLocation e GetObject.
    • ListBucket è necessario per le tabelle esterne o le query OPENROWSET che puntano a un percorso di cartella S3 anziché di un singolo file. Senza autorizzazioni ListBucket, verrà visualizzato l'errore 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.
  • L'autorizzazione PutObject è necessaria per scrivere nell'archiviazione oggetti S3.

Suggerimento

Il provider di archiviazione oggetti conforme a S3 potrebbe richiedere autorizzazioni aggiuntive per le operazioni API o usare nomi diversi per i ruoli contenenti le autorizzazioni per le operazioni API. Vedere la documentazione del prodotto.

Abilitare PolyBase

  1. Abilitare PolyBase in sp_configure:

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

  2. Confermare l'impostazione:

    EXEC sp_configure @configname = 'polybase enabled';

Autenticazione

Per continuare, scegliere Autenticazione di base o autorizzazione pass-through (STS).

Autenticazione di base

Prima di creare credenziali con ambito database, il database utente deve avere una chiave master per proteggerle. Per altre informazioni, vedere CREATE MASTER KEY.

Creare credenziali con ambito database con autenticazione di base

Lo script di esempio seguente crea una credenziale s3-dc con ambito database nel database database_name in un'istanza di SQL Server. Per altre informazioni sulle credenziali, vedere 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

Verificare le nuove credenziali con ambito database con sys.database_scoped_credentials (Transact-SQL):

SELECT * FROM sys.database_scoped_credentials;

Creare un'origine dati esterna con l'autenticazione di base

Lo script di esempio seguente crea un'origine dati esterna s3_ds nel database utente di origine in SQL Server. L'origine dati esterna fa riferimento alle credenziali con ambito database di s3_dc. Per altre informazioni, vedere CREATE EXTERNAL DATA SOURCE.

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

Verificare la nuova origine dati esterna con sys.external_data_sources.

SELECT * FROM sys.external_data_sources;

URL ospitati virtuali

Alcuni sistemi di archiviazione compatibili con S3, ad esempio Amazon Web Services, usano gli URL di stile virtual_hosted per implementare la struttura di cartelle nel bucket S3. Aggiungere CONNECTION_OPTIONS seguente per consentire la creazione di tabelle esterne che puntano ai percorsi delle cartelle nel bucket S3, ad esempio CONNECTION_OPTIONS = '{"s3":{"url_style":"virtual_hosted"}}'.

Senza questa impostazione CONNECTION_OPTIONS, quando si eseguono query su tabelle esterne che puntano a una cartella, è possibile osservare l'errore seguente:

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

Limitazioni dell'autenticazione di base

  • Per l'archiviazione di oggetti compatibile con S3, ai clienti non è consentito creare l'ID chiave di accesso contenente un carattere :.
  • La lunghezza totale dell'URL è limitata a 259 caratteri. Ciò significa che s3://<hostname>/<objectkey> non può superare i 259 caratteri. s3:// conta a fronte di questo limite, quindi la lunghezza del percorso non può superare 259-5 = 254 caratteri.
  • Il nome delle credenziali SQL è limitato a 128 caratteri in formato UTF-16.
  • Il nome delle credenziali creato deve contenere il nome del bucket, a meno che questa credenziale non sia per una nuova origine dati esterna.
  • L'ID chiave di accesso e l'ID chiave privata possono contenere solo valori alfanumerici.

Autorizzazione pass-through (STS)

Le risorse di archiviazione oggetti compatibili con S3 hanno la possibilità di assegnare credenziali temporanee usando il servizio token di sicurezza (STS). Tali credenziali sono a breve termine e vengono generate in modo dinamico.

L'autorizzazione pass-through si basa su Active Directory Federation Service (ADFS) che funge da provider di identità OpenID Connect (OIDC); spetta ad ADFS comunicare con il servizio token di sicurezza delle risorse di storage degli oggetti compatibile con S3, richiedere il servizio token di sicurezza e restituirlo a SQL Server.

Usare l'autorizzazione pass-through (STS) in SQL Server

  1. TLS deve essere configurato mediante certificati tra SQL Server e il server host compatibile con S3. Si presuppone che tutte le connessioni vengano trasmesse in modo sicuro tramite HTTPS, non HTTP. L'endpoint verrà convalidato da un certificato installato nell'host del sistema operativo di SQL Server. Sono supportati i certificati pubblici o autofirmati.

  2. Creare una credenziale con ambito database che verrà usata per passare l'identità alle risorse di archiviazione di oggetti compatibili con S3. Per ulteriori informazioni, consultare CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL). Nell'esempio seguente:

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

  3. Creare un'origine dati esterna per accedere alle risorse di archiviazione oggetti compatibili con S3. Usare CONNECTION_OPTIONS, come formato JSON, per informare le informazioni necessarie sia per ADFS che per il servizio token di sicurezza. Per altre informazioni, vedere CREATE EXTERNAL DATA SOURCE. Nell'esempio seguente:

    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"
            } ]
    }' ]
}
  • Le opzioni ADFS specificano l'endpoint di trasporto Windows e l'identificatore relying_party di SQL Server in ADFS.
  • Le opzioni STS specificano l'endpoint e i parametri del servizio token di sicurezza delle risorse di archiviazione oggetti compatibili con S3 per la richiesta AssumeRoleWithWebIdentity. AssumeRoleWithWebIdentity è il metodo utilizzato per acquisire le credenziali di sicurezza temporanee usate per l'autenticazione. Per l'elenco completo dei parametri, inclusi quelli facoltativi e le informazioni sui valori predefiniti, vedere Informazioni di riferimento API STS.

Usare l'autorizzazione pass-through (STS) con Active Directory

  • Contrassegnare le proprietà degli account utente di SQL Server in AD come non sensibili per consentire il pass-through alle risorse di archiviazione compatibili con S3.
  • Consentire la delega vincolata Kerberos ai servizi ADFS per l'utente correlato al nome SPN di SQL Server (nome dell'entità servizio).

Usare l'autorizzazione pass-through (STS) con Active Directory Federation Service

  • Abilitare SQL Server come trust del provider di attestazioni in Active Directory.
  • Consentire l'autenticazione di Windows intranet come metodi di autenticazione per ADFS.
  • Abilitare l'endpoint del servizio di trasporto Windows nella rete intranet.
  • Abilitare gli endpoint OIDC (OpenID Connect).
  • Registrare SQL Server come attendibilità della relying party.
    • Fornire un identificatore univoco
    • Impostare le regole delle attestazioni per JWT (token JSON Web).
  • Attestazioni personalizzate: queste attestazioni possono essere aggiunte dai clienti, se necessarie per determinare i criteri di accesso sul lato archiviazione.
  • Per altre informazioni specifiche del fornitore, rivolgersi all’operatore di piattaforma compatibile con S3.

Usare l'autorizzazione pass-through (STS) nell'archiviazione oggetti compatibile con S3

  • Seguire la documentazione fornita dal provider di archiviazione compatibile con S3 per configurare il provider di identità OIDC esterno. Per configurare il provider di identità, sono in genere necessari i valori seguenti.

    • Endpoint di configurazione del provider OIDC.
    • Identificazione personale del provider OIDC.
    • Autorizzazione pass-through all'archiviazione oggetti compatibile con S3

Limitazioni dell'autorizzazione pass-through (STS)

  • L'autorizzazione pass-through (STS) all'archiviazione oggetti compatibile con S3 è supportata per gli accessi di SQL Server con autenticazione di Windows.
  • I token STS non possono essere usati per BACKUP su URL per l'archiviazione di oggetti compatibile con S3.
  • ADFS e SQL Server devono trovarsi nello stesso dominio. L'endpoint di trasporto Windows ADFS deve essere disabilitato dalla extranet.
  • ADFS deve avere lo stesso AD (Active Directory) di SQL Server come provider di attendibilità attestazione.
  • L'archiviazione compatibile con S3 deve avere un servizio endpoint STS che consenta ai client di richiedere credenziali temporanee usando JWT di identità esterne.
  • Le query OPENROWSET e CETAS (Create External Table as Select) sono supportate per il formato parquet e CSV.
  • Per impostazione predefinita, il tempo di rinnovo del ticket Kerberos è di sette giorni e la durata è di 10 ore in Windows e 2 ore in Linux. SQL Server rinnova il token Kerberos dell'utente fino a sette giorni. Dopo sette giorni il ticket dell'utente scade, pertanto il pass-through all'archiviazione compatibile con S3 avrà esito negativo. In questo caso, SQL Server deve autenticare nuovamente l'utente per ottenere un nuovo ticket Kerberos.
  • ADFS 2019 con Windows Server 2019 è supportato.
  • Le chiamate API REST S3 usano la firma AWS versione 4.

PolyBase in SQL Server in Linux

Per PolyBase in SQL Server in Linux, sono necessarie altre configurazioni.

  • È necessario configurare TLS. Si presuppone che tutte le connessioni vengano trasmesse in modo sicuro tramite HTTPS non HTTP. L'endpoint viene convalidato da un certificato installato nell'host del sistema operativo di SQL Server.
  • La gestione dei certificati è diversa in Linux. Esaminare e seguire la configurazione dettagliata nel supporto di Linux per l'archiviazione compatibile con S3.

Contenuto correlato