Bagikan melalui

Mengonfigurasi PolyBase untuk mengakses data eksternal di penyimpanan objek yang kompatibel dengan S3

  • Artikel

Berlaku untuk: SQL Server 2022 (16.x)

Artikel ini menjelaskan cara menggunakan PolyBase untuk mengkueri data eksternal di penyimpanan objek yang kompatibel dengan S3.

SQL Server 2022 (16.x) memperkenalkan kemampuan untuk terhubung ke penyimpanan objek yang kompatibel dengan S3, ada dua opsi yang tersedia untuk autentikasi: autentikasi dasar atau otorisasi pass-through (juga dikenal sebagai otorisasi STS).

Autentikasi Dasar, juga dikenal sebagai kredensial statis, mengharuskan pengguna untuk menyimpan access key id dan secret key id di SQL Server, terserah pengguna untuk secara eksplisit mencabut dan memutar kredensial setiap kali diperlukan. Kontrol akses mendetail akan mengharuskan administrator untuk menyiapkan kredensial statis untuk setiap login, pendekatan ini bisa menjadi tantangan saat berhadapan dengan puluhan atau ratusan kredensial unik.

Otorisasi pass-through (STS) menawarkan solusi untuk masalah ini dengan mengaktifkan penggunaan identitas pengguna SQL Server sendiri untuk mengakses penyimpanan objek yang kompatibel dengan S3. Penyimpanan objek yang kompatibel dengan S3 memiliki kemampuan untuk menetapkan kredensial sementara dengan menggunakan Secure Token Service (STS). Kredensial ini bersifat jangka pendek dan dihasilkan secara dinamis.

Artikel ini mencakup instruksi untuk otorisasi Autentikasi Dasar dan otorisasi pass-through (STS).

Prasyarat

Untuk menggunakan fitur integrasi penyimpanan objek yang kompatibel dengan S3, Anda memerlukan alat dan sumber daya berikut:

  • Instal fitur PolyBase untuk SQL Server.
  • Instal SQL Server Management Studio (SSMS) atau Azure Data Studio.
  • Penyimpanan yang kompatibel dengan S3.
  • Wadah S3 dibuat. Wadah tidak dapat dibuat atau dikonfigurasi dari SQL Server.
  • Pengguna (Access Key ID) dan rahasia (Secret Key ID) yang diketahui oleh Anda. Anda memerlukan keduanya untuk mengautentikasi terhadap titik akhir penyimpanan objek S3.
  • Keamanan Lapisan Transportasi (TLS) harus dikonfigurasi. Diasumsikan bahwa semua koneksi akan ditransmisikan dengan aman melalui HTTPS bukan HTTP. Titik akhir akan divalidasi oleh sertifikat yang diinstal pada Host OS SQL Server. Untuk informasi selengkapnya tentang TLS dan sertifikat, lihat Mengaktifkan koneksi terenkripsi ke Mesin Database.

Izin

Agar pengguna proksi membaca konten wadah S3, pengguna (Access Key ID) harus diizinkan untuk melakukan tindakan berikut terhadap titik akhir S3:

  • Izin GetBucketLocation dan GetObject diperlukan untuk membaca file tertentu dari penyimpanan objek S3.
    • ListBucket diperlukan untuk tabel eksternal atau kueri OPENROWSET yang menunjuk ke lokasi folder S3, bukan satu file. Tanpa izin ListBucket , Anda akan menerima kesalahan 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.
  • Izin PutObject diperlukan untuk menulis ke penyimpanan objek S3.

Tip

Penyedia penyimpanan objek yang mematuhi S3 Anda mungkin memerlukan izin operasi API tambahan, atau menggunakan penamaan yang berbeda untuk peran yang berisi izin ke operasi API. Lihat dokumentasi produk Anda.

Aktifkan PolyBase

  1. Aktifkan PolyBase di sp_configure:

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

  2. Konfirmasi pengaturan:

    EXEC sp_configure @configname = 'polybase enabled';

Autentikasi

Untuk melanjutkan, pilih Otorisasi Autentikasi Dasar atau pass-through (STS).

Autentikasi Dasar

Sebelum Anda membuat kredensial lingkup database, database pengguna harus memiliki kunci master untuk melindungi kredensial. Untuk informasi selengkapnya, lihat MEMBUAT KUNCI MASTER.

Membuat kredensial lingkup database dengan Autentikasi Dasar

Contoh skrip berikut membuat kredensial s3-dc cakupan database dalam database_name database dalam instans SQL Server. Untuk informasi selengkapnya, lihat MEMBUAT KREDENSIAL CAKUPAN DATABASE (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

Verifikasi kredensial cakupan database baru dengan sys.database_scoped_credentials (Transact-SQL):

SELECT * FROM sys.database_scoped_credentials;

Membuat sumber data eksternal dengan Autentikasi Dasar

Contoh skrip berikut membuat sumber s3_ds data eksternal di database pengguna sumber di SQL Server. Sumber data eksternal mereferensikan s3_dc kredensial cakupan database. Untuk informasi selengkapnya, lihat MEMBUAT SUMBER DATA EKSTERNAL.

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

Verifikasi sumber data eksternal baru dengan sys.external_data_sources.

SELECT * FROM sys.external_data_sources;

URL yang dihosting virtual

Beberapa sistem penyimpanan yang kompatibel dengan S3 (seperti Amazon Web Services) menggunakan virtual_hosted URL gaya untuk menerapkan struktur folder dalam wadah S3. Tambahkan yang berikut ini CONNECTION_OPTIONS untuk memungkinkan pembuatan tabel eksternal yang menunjuk ke lokasi folder di wadah S3, misalnya CONNECTION_OPTIONS = '{"s3":{"url_style":"virtual_hosted"}}'.

Tanpa pengaturan tersebut CONNECTION_OPTIONS , saat mengkueri tabel eksternal yang menunjuk ke folder, Anda mungkin mengamati kesalahan berikut:

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

Batasan Autentikasi Dasar

  • Untuk penyimpanan objek yang kompatibel dengan S3, pelanggan tidak diizinkan untuk membuat ID kunci akses mereka dengan : karakter di dalamnya.
  • Panjang URL total dibatasi hingga 259 karakter. Ini berarti s3://<hostname>/<objectkey> tidak boleh melebihi 259 karakter. Hitungan s3:// terhadap batas ini, sehingga panjang jalur tidak boleh melebihi 259-5 = 254 karakter.
  • Nama kredensial SQL dibatasi oleh 128 karakter dalam format UTF-16.
  • Nama kredensial yang dibuat harus berisi nama wadah kecuali kredensial ini untuk sumber data eksternal baru.
  • ID Kunci Akses dan ID Kunci Rahasia hanya boleh berisi nilai alfanumerik.

Otorisasi pass-through (STS)

Penyimpanan objek yang kompatibel dengan S3 memiliki kemampuan untuk menetapkan kredensial sementara dengan menggunakan Secure Token Service (STS). Kredensial ini bersifat jangka pendek dan dihasilkan secara dinamis.

Otorisasi pass-through bergantung pada Layanan Federasi Direktori Aktif (ADFS) yang bertindak sebagai penyedia identitas OpenID Connect (OIDC), terserah ADFS untuk berkomunikasi dengan STS penyimpanan objek yang kompatibel dengan S3, meminta STS dan menyediakannya kembali ke SQL Server.

Menggunakan otorisasi pass-through (STS) di SQL Server

  1. TLS harus dikonfigurasi dengan sertifikat antara SQL Server dan server host yang kompatibel dengan S3. Diasumsikan bahwa semua koneksi akan ditransmisikan dengan aman melalui HTTPS, bukan HTTP. Titik akhir akan divalidasi oleh sertifikat yang diinstal pada Host OS SQL Server. Sertifikat publik atau yang ditandatangani sendiri didukung.

  2. Buat kredensial cakupan database yang akan digunakan untuk meneruskan identitas ke penyimpanan objek yang kompatibel dengan S3. Untuk informasi selengkapnya, lihat MEMBUAT KREDENSIAL CAKUPAN DATABASE (Transact-SQL). Sebagai contoh berikut:

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

  3. Buat sumber data eksternal untuk mengakses penyimpanan objek yang kompatibel dengan S3. Gunakan CONNECTION_OPTIONS, sebagai format JSON, untuk menginformasikan informasi yang diperlukan untuk ADFS dan STS. Untuk informasi selengkapnya, lihat MEMBUAT SUMBER DATA EKSTERNAL. Sebagai contoh berikut:

    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 opsi menentukan titik akhir transportasi Windows dan relying_party pengidentifikasi SQL Server di ADFS.
  • STS opsi menentukan titik akhir dan parameter STS penyimpanan objek yang kompatibel dengan S3 untuk AssumeRoleWithWebIdentity permintaan. AssumeRoleWithWebIdentity adalah metode yang digunakan untuk memperoleh kredensial keamanan sementara yang digunakan untuk mengautentikasi. Untuk daftar lengkap parameter, termasuk parameter opsional, dan informasi tentang nilai default, lihat Referensi STS API.

Menggunakan otorisasi pass-through (STS) dengan Direktori Aktif

  • Tandai properti akun pengguna SQL Server di AD sebagai tidak sensitif untuk memungkinkan pass-through ke penyimpanan yang kompatibel dengan S3.
  • Izinkan delegasi yang dibatasi Kerberos ke layanan ADFS untuk pengguna yang terkait dengan SQL Server SPN (Nama Perwakilan Layanan).

Menggunakan otorisasi pass-through (STS) dengan Layanan Federasi Direktori Aktif

  • Aktifkan SQL Server untuk menjadi kepercayaan penyedia klaim di Direktori Aktif.
  • Izinkan autentikasi windows intranet sebagai metode autentikasi untuk ADFS.
  • Aktifkan titik akhir layanan transportasi windows di intranet Anda.
  • Aktifkan titik akhir OIDC (OpenID Connect).
  • Daftarkan SQL Server sebagai kepercayaan pihak yang mengandalkan.
    • Berikan pengidentifikasi unik.
    • Tetapkan aturan klaim untuk JWT (JSON Web Token).
  • Klaim kustom - Klaim ini dapat ditambahkan oleh pelanggan jika diperlukan untuk menentukan kebijakan akses di sisi penyimpanan.
  • Untuk informasi khusus vendor lainnya, tanyakan kepada penyedia platform yang kompatibel dengan S3 Anda.

Menggunakan otorisasi pass-through (STS) pada penyimpanan objek yang kompatibel dengan S3

  • Ikuti dokumentasi yang disediakan oleh penyedia penyimpanan yang kompatibel dengan S3 untuk menyiapkan idP OIDC eksternal. Untuk menyiapkan penyedia identitas, sebagian besar nilai berikut umumnya diperlukan.

    • Titik akhir konfigurasi penyedia OIDC.
    • Thumbprint penyedia OIDC.
    • Otorisasi pass-through ke penyimpanan objek yang kompatibel dengan S3

Batasan otorisasi pass-through (STS)

  • Otorisasi pass-through (STS) ke penyimpanan objek yang kompatibel dengan S3 didukung untuk masuk SQL Server dengan autentikasi Windows.
  • Token STS tidak dapat digunakan untuk BACKUP ke URL untuk penyimpanan objek yang kompatibel dengan S3.
  • ADFS dan SQL Server harus berada di domain yang sama. Titik akhir transportasi ADFS Windows harus dinonaktifkan dari ekstranet.
  • ADFS harus memiliki AD (Direktori aktif) yang sama dengan SQL Server sebagai penyedia kepercayaan klaim.
  • Penyimpanan yang kompatibel dengan S3 harus memiliki layanan titik akhir STS yang memungkinkan klien meminta kredensial sementara menggunakan JWT identitas eksternal.
  • Kueri OPENROWSET dan CETAS (Buat Tabel Eksternal sebagai Pilih) didukung untuk format parquet dan CSV.
  • Secara default, waktu perpanjangan tiket Kerberos adalah tujuh hari dan masa pakai adalah 10 jam di Windows dan 2 jam di Linux. SQL Server memperbarui token Kerberos pengguna hingga tujuh hari. Setelah tujuh hari tiket pengguna kedaluwarsa, oleh karena itu pass-through ke penyimpanan yang kompatibel dengan S3 akan gagal. Dalam hal ini, SQL Server harus mengautentikasi ulang pengguna untuk mendapatkan tiket Kerberos baru.
  • ADFS 2019 dengan Windows Server 2019 didukung.
  • Panggilan S3 REST API menggunakan tanda tangan AWS versi 4.

PolyBase di SQL Server di Linux

Untuk PolyBase di SQL Server di Linux, diperlukan lebih banyak konfigurasi.

  • TLS harus dikonfigurasi. Diasumsikan bahwa semua koneksi akan ditransmisikan dengan aman melalui HTTPS bukan HTTP. Titik akhir divalidasi oleh sertifikat yang diinstal pada Host OS SQL Server.
  • Manajemen sertifikat berbeda di Linux. Tinjau dan ikuti konfigurasi yang dirinci dalam dukungan Linux untuk penyimpanan yang kompatibel dengan S3.

Konten terkait