Configuración de PolyBase para acceder a datos externos en el almacenamiento de objetos compatible con S3

  • Artículo

Se aplica a: SQL Server 2022 (16.x)

En este artículo se explica cómo usar PolyBase para consultar datos externos en un almacenamiento de objetos compatible con S3.

SQL Server 2022 (16.x) presenta la capacidad de conectarse a cualquier almacenamiento de objetos compatible con S3. Hay dos opciones disponibles para la autenticación: autenticación básica o autorización de paso a través (también conocida como autorización STS).

La autenticación básica, también conocida como credenciales estáticas, requiere que el usuario almacene access key id y secret key id en SQL Server. Es necesario que el usuario revoque explícitamente y rote las credenciales siempre que sea necesario. El control de acceso específico requeriría que el administrador configurase credenciales estáticas para cada inicio de sesión. Este enfoque puede ser difícil al tratar con docenas o cientos de credenciales únicas.

La autorización de paso a través (STS) ofrece una solución para estos problemas al habilitar el uso de identidades de usuario propias de SQL Server para acceder al almacenamiento de objetos compatible con S3. El almacenamiento de objetos compatible con S3 tiene la capacidad de asignar una credencial temporal mediante el uso del servicio de token de seguridad (STS). Estas credenciales se generan a corto plazo y dinámicamente.

En este artículo se incluyen instrucciones para la autenticación básica y la autorización de paso a través (STS).

Requisitos previos

Para usar las características de integración del almacenamiento de objetos compatible con S3, necesitará los siguientes recursos y herramientas:

  • Instale la característica PolyBase para SQL Server.
  • Instale SQL Server Management Studio (SSMS) o Azure Data Studio.
  • Almacenamiento compatible con S3.
  • Se ha creado un cubo de S3. Los cubos no se pueden crear ni configurar desde SQL Server.
  • Un usuario (Access Key ID) y el secreto (Secret Key ID) que conozca. Necesitará ambos para autenticarse en el punto de conexión de almacenamiento de objetos S3.
  • Permiso ListBucket en el usuario de S3 para privilegios de exploración.
  • Permiso ReadOnly en el usuario de S3 para privilegios de lectura.
  • Permiso WriteOnly en el usuario de S3 para privilegios de escritura.
  • Debe configurar la seguridad de la capa de transporte (TLS). Se presupone que todas las conexiones se transmitirán de forma segura a través de HTTPS, no de HTTP. Un certificado instalado en el host del sistema operativo de SQL Server validará el punto de conexión. Para más información sobre TLS y los certificados, vea Habilitación de conexiones cifradas en el motor de base de datos.

Permisos

Para que el usuario de proxy lea el contenido de un cubo de S3, deberá permitirse que el usuario realice las siguientes acciones en el punto de conexión de S3:

  • En AWS S3, cree un rol personalizado y, específicamente, indique qué API de S3 necesita acceso.
    • La copia de seguridad necesita estos permisos: ListBucket (exploración), PutObject (escritura: para la copia de seguridad).
    • La restauración necesita estos permisos: ListBucket (exploración), GetObject (lectura: para restaurar), GetObject (lectura: para la restauración).
  • En otro almacenamiento compatible con S3:
    • La copia de seguridad necesita que el usuario (Access Key ID) tenga los permisos ListBucket y WriteOnly.
    • La restauración necesita que el usuario (Access Key ID) tenga los permisos ListBucket y ReadOnly.

Habilitar PolyBase

  1. Habilitar PolyBase en sp_configure:

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

  2. Confirme la configuración:

    EXEC sp_configure @configname = 'polybase enabled';

Autenticación

Para continuar, elija Autenticación básica o autorización de paso a través (STS).

Autenticación básica

Para poder crear una credencial con ámbito de base de datos, la base de datos debe tener una clave maestra para proteger la credencial. Para obtener más información, vea CREATE MASTER KEY.

Creación de una credencial con ámbito de base de datos con autenticación básica

El siguiente script de ejemplo crea una credencial de ámbito de base de datos s3-dc en la base de datos database_name de una instancia de SQL Server. Para obtener más información, consulte 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

Compruebe la nueva credencial de ámbito de base de datos con sys.database_scoped_credentials (Transact-SQL):

SELECT * FROM sys.database_scoped_credentials;

Creación de un origen de datos externo con autenticación básica

El siguiente script de ejemplo crea un origen de datos externo s3_ds en la base de datos de usuario de origen de SQL Server. El origen de datos externo hace referencia a la credencial de ámbito de base de datos s3_dc. Para más información, vea CREATE EXTERNAL DATA SOURCE.

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

Compruebe el nuevo origen de datos externo con sys.external_data_sources.

SELECT * FROM sys.external_data_sources;

Limitaciones de la autenticación básica

  1. En el caso del almacenamiento de objetos compatible con S3, los clientes no pueden crear su identificador de clave de acceso con un carácter : en él.
  2. La longitud total de la dirección URL no puede superar los 259 caracteres. Esto significa que s3://<hostname>/<objectkey> no debe superar los 259 caracteres. s3:// cuenta para este límite, por lo que la ruta de acceso no puede tener una longitud superior a 259-5 = 254 caracteres.
  3. El nombre de la credencial de SQL está limitado a 128 caracteres en formato UTF-16.
  4. El nombre de la credencial creado debe contener el nombre del cubo a menos que esta credencial sea para un nuevo origen de datos externo.
  5. El identificador de clave de acceso y el identificador de clave secreta solo pueden contener valores alfanuméricos.

Autorización de paso a través (STS)

El almacenamiento de objetos compatible con S3 tiene la capacidad de asignar una credencial temporal mediante el uso del servicio de token de seguridad (STS). Estas credenciales se generan a corto plazo y dinámicamente.

La autorización de paso a través se basa en el proveedor de identidades del Servicio de federación de Active Directory (ADFS) que actúa como proveedor de identidades de OpenID Connect (OIDC). Depende del ADFS comunicarse con el STS compatible con S3, solicitar el STS y devolverlo a SQL Server.

Uso de la autorización de paso a través (STS) en SQL Server

  1. TLS debe configurarse con certificados entre SQL Server y el servidor host compatible con S3. Se presupone que todas las conexiones se transmitirán de forma segura a través de HTTPS, no de HTTP. Un certificado instalado en el host del sistema operativo de SQL Server validará el punto de conexión. No se admiten certificados autofirmados ni públicos.

  2. Cree una credencial con ámbito de base de datos que se usará para pasar la identidad al almacenamiento de objetos compatible con S3. Para obtener más información, consulte CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL). Como se muestra en el ejemplo siguiente:

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

  3. Cree un origen de datos externo para acceder al almacenamiento de objetos compatible con S3. Use CONNECTION_OPTIONS, como formato JSON, para informar de la información necesaria para ADFS y STS. Para más información, vea CREATE EXTERNAL DATA SOURCE. Como se muestra en el ejemplo siguiente:

    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"
            } ]
    }' ]
}
  • Las opciones de ADFS especifican el punto de conexión de transporte de Windows y el identificador relying_party de SQL Server en ADFS.
  • Las opciones de STS especifican el punto de conexión y los parámetros de STS de almacenamiento de objetos compatible con S3 para la solicitud AssumeRoleWithWebIdentity. AssumeRoleWithWebIdentity es el método que se usa para adquirir la credencial de seguridad temporal que se usa para autenticarse. Para obtener la lista completa de parámetros, incluidos los opcionales, y la información sobre los valores predeterminados, consulte Referencia de API de STS.

Uso de la autorización de paso a través (STS) con Active Directory

  • Marque las propiedades de las cuentas de usuario de SQL Server en AD como no confidenciales para permitir el tránsito hacia el almacenamiento compatible con S3.
  • Permite la delegación restringida de Kerberos a los servicios de ADFS para el usuario relacionado con el SPN (nombres de entidad de seguridad de servicio) de SQL Server.

Uso de la autorización de paso a través (STS) con el Servicio de federación de Active Directory

  • Permita que SQL Server sea un proveedor de notificaciones de confianza en Active Directory.
  • Permita la autenticación de Windows de intranet como método de autenticación para ADFS.
  • Habilite el punto de conexión de servicio de transporte de Windows en la intranet.
  • Habilite los puntos de conexión de OIDC (OpenID Connect).
  • Registre SQL Server como una relación de confianza para usuario autenticado.
    • Proporcione un identificador único.
    • Establezca reglas de notificaciones para JWT (JSON Web Token).
  • Notificaciones personalizadas: los clientes pueden agregar estas notificaciones si son necesarias para determinar la directiva de acceso en el lado de almacenamiento.
  • Para obtener más información específica del proveedor, consulte con el proveedor de plataforma compatible con S3.

Uso de la autorización de paso a través (STS) en el almacenamiento de objetos compatible con S3

  • Siga la documentación proporcionada por el proveedor de almacenamiento compatible con S3 para configurar el proveedor de identidades OIDC externo. Para configurar el proveedor de identidades, principalmente se necesitan los valores siguientes.

    • Punto de conexión de configuración del proveedor OIDC.
    • Huella digital del proveedor OIDC.
    • Autorización de paso a través al almacenamiento de objetos compatible con S3

Limitaciones de la autorización de paso a través (STS)

  • La autorización de tránsito (STS) hacia el almacenamiento de objetos compatible con S3 se admite para los inicios de sesión de SQL Server con autenticación de Windows.
  • Los tokens STS no se pueden usar como copia de seguridad para direcciones URL para el almacenamiento de objetos compatible con S3.
  • ADFS y SQL Server deben estar en el mismo dominio. El punto de conexión de transporte de Windows de ADFS debe deshabilitarse desde la extranet.
  • ADFS debe tener la misma instancia de AD (Active Directory) que SQL Server como proveedor de confianza de notificaciones.
  • El almacenamiento compatible con S3 debe tener un servicio de punto de conexión STS que permita a los clientes solicitar credenciales temporales mediante JWT de identidades externas.
  • Las consultas OPENROWSET y CETAS (Crear tabla externa como selección) se admiten para el formato parquet y CSV.
  • De forma predeterminada, el tiempo de renovación de vales de Kerberos es de siete días y la duración es de 10 horas en Windows y 2 horas en Linux. SQL Server renueva el token de Kerberos del usuario hasta siete días. Después de siete días, el vale del usuario expira, por lo tanto, se producirá un error en el paso a través para el almacenamiento compatible con S3. En este caso, SQL Server debe volver a autenticar al usuario para obtener un nuevo vale de Kerberos.
  • Se admitirá ADFS 2019 con Windows Server 2019.
  • Las llamadas a la API de REST de S3 usarán la versión 4 de la firma de AWS.

Contenido relacionado