Condividi tramite


Distribuire un'Istanza gestita di SQL integrata in Active Directory abilitata da Azure Arc

Questo articolo illustra come distribuire un'Istanza gestita di SQL di Azure abilitata per Azure Arc con l'autenticazione di Active Directory.

Prerequisiti

Prima di iniziare la distribuzione dell'Istanza gestita di SQL, verificare che siano disponibili i seguenti prerequisiti:

Requisiti del connettore

Le modalità di distribuzione di Active Directory Connector in modalità keytab gestita dal cliente e in modalità keytab gestita dal sistema sono diverse e prevedono requisiti e passaggi diversi. Ogni modalità presenta requisiti specifici durante la distribuzione. Selezionare la scheda per il connettore in uso.

Per una distribuzione di Active Directory in modalità keytab gestita dal cliente, è necessario specificare:

  • Un account utente Active Directory per SQL
  • I nomi dell'entità servizio (SPN) nell'account utente
  • Un record DNS A (inoltro) per l'endpoint primario di SQL (e, facoltativamente, un endpoint secondario)

Preparare la distribuzione

In base alla modalità di distribuzione, completare la procedura seguente per preparare la distribuzione dell'Istanza gestita di SQL.

Per prepararsi alla distribuzione in modalità keytab gestita dal cliente:

  1. Identificare un nome DNS per gli endpoint SQL: scegliere nomi DNS univoci per gli endpoint SQL ai quali si connetteranno i client esternamente dal cluster Kubernetes.

    • I nomi DNS devono trovarsi nel dominio di Active Directory o nei domini discendenti.
    • Negli esempi riportati in questo articolo si usa sqlmi-primary.contoso.local per il nome DNS primario e sqlmi-secondary.contoso.local per il nome DNS secondario.
  2. Identificare i numeri di porta per gli endpoint SQL: immettere un numero di porta per ciascun endpoint SQL.

    • I numeri di porta devono rientrare nell'intervallo accettabile di numeri di porta per il cluster Kubernetes.
    • Negli esempi contenuti in questo articolo si usa 31433 per il numero di porta primario e 31434 per il numero di porta secondario.
  3. Creare un account Active Directory per l'istanza gestita: scegliere un nome per l'account Active Directory che rappresenti l'istanza gestita.

    • Il nome deve essere univoco nel dominio Active Directory.
    • Negli esempi riportati in questo articolo si usa sqlmi-account per il nome dell'account Active Directory.

    Per creare l'account:

    1. Nel controller di dominio aprire lo strumento Utenti e computer di Active Directory. Creare un account per rappresentare l'istanza gestita.
    2. Immettere una password dell'account conforme ai criteri password del dominio di Active Directory. Questa password verrà utilizzata in alcuni passaggi delle sezioni successive.
    3. Assicurarsi che l'account sia abilitato. L'account non necessita di autorizzazioni speciali.
  4. Creare record DNS per gli endpoint SQL nei server DNS di Active Directory: in uno dei server DNS di Active Directory, creare dei record A (record di ricerca diretta) per il nome DNS scelto nel passaggio 1.

    • I record DNS devono puntare all'indirizzo IP sul quale l'endpoint SQL rimarrà in ascolto per le connessioni all'esterno del cluster Kubernetes.
    • Non è necessario creare record PTR (di ricerca inversa puntatore) in associazione con i record A.
  5. Creare nomi delle entità di servizio (SPN): per consentire a SQL di accettare l'autenticazione di Active Directory sugli endpoint SQL, è necessario registrare due nomi di entità di servizio nell'account creato nel passaggio precedente. È necessario registrare due nomi delle entità di servizio per l'endpoint primario. Se si desidera l'autenticazione di Active Directory per l'endpoint secondario, è necessario registrare anche i nomi delle entità di servizio per l'endpoint secondario.

    Per creare e registrare nomi delle entità di servizio:

    1. Usare il formato seguente per creare i nomi delle entità di servizio:

      MSSQLSvc/<DNS name>
      MSSQLSvc/<DNS name>:<port>
      
    2. In uno dei controller di dominio eseguire i comandi seguenti per registrare i nomi delle entità di servizio:

      setspn -S MSSQLSvc/<DNS name> <account>
      setspn -S MSSQLSvc/<DNS name>:<port> <account>
      

      I comandi potrebbero essere simili a quelli riportati nell'esempio seguente:

      setspn -S MSSQLSvc/sqlmi-primary.contoso.local sqlmi-account
      setspn -S MSSQLSvc/sqlmi-primary.contoso.local:31433 sqlmi-account
      
    3. Se si desidera l'autenticazione di Active Directory nell'endpoint secondario, eseguire gli stessi comandi per aggiungere gli SPN per l'endpoint secondario:

      setspn -S MSSQLSvc/<DNS name> <account>
      setspn -S MSSQLSvc/<DNS name>:<port> <account>
      

      I comandi potrebbero essere simili a quelli riportati nell'esempio seguente:

      setspn -S MSSQLSvc/sqlmi-secondary.contoso.local sqlmi-account
      setspn -S MSSQLSvc/sqlmi-secondary.contoso.local:31434 sqlmi-account
      
  6. Generare un file keytab contenente voci per l'account e i nomi delle entità di servizio: per consentire a SQL di autenticarsi in Active Directory e accettare l'autenticazione da parte degli utenti di Active Directory, fornire un file keytab utilizzando un segreto Kubernetes.

    • Il file keytab contiene voci crittografate per l'account Active Directory generato per l'istanza gestita e i nomi SPN.

    • SQL Server usa questo file come credenziali per Active Directory.

    • Per generare un file keytab, è possibile scegliere tra diversi strumenti:

      • adutil: disponibile per Linux (vedere Introduzione ad adutil)
      • ktutil: disponibile su Linux
      • ktpass: disponibile su Windows
      • Script personalizzati

    Per generare il file keytab in modo specifico per l'istanza gestita:

    1. Usare uno di questi script personalizzati:

      Gli script accettano diversi parametri e generano un file keytab e un file di specifica YAML per il segreto Kubernetes che contiene il keytab.

    2. Nello script, sostituire i valori dei parametri con i valori per la distribuzione dell'istanza gestita.

      Per i parametri di input, usare i valori seguenti:

      • --realm: il dominio di Active Directory in lettere maiuscole. Esempio: CONTOSO.LOCAL
      • --account: l'account Active Directory in cui sono registrati i nomi SPN. Esempio: sqlmi-account
      • --port: il numero di porta dell'endpoint SQL primario. Esempio: 31433
      • --dns-name: il nome DNS dell'endpoint SQL primario.
      • --keytab-file: il percorso del file keytab.
      • --secret-name: il nome del segreto keytab per cui generare una specifica.
      • --secret-namespace: lo spazio dei nomi Kubernetes che contiene il segreto keytab.
      • --secondary-port: il numero di porta dell'endpoint SQL secondario (facoltativo). Esempio: 31434
      • --secondary-dns-name: il nome DNS per l'endpoint SQL secondario (facoltativo).

      Scegliere un nome per il segreto Kubernetes che ospita il keytab. Usare lo spazio dei nomi in cui viene distribuita l'istanza gestita.

    3. Eseguire il comando seguente per creare un keytab:

      AD_PASSWORD=<password> ./create-sql-keytab.sh --realm <Active Directory domain in uppercase> --account <Active Directory account name> --port <endpoint port> --dns-name <endpoint DNS name> --keytab-file <keytab file name/path> --secret-name <keytab secret name> --secret-namespace <keytab secret namespace>
      

      Il comando potrebbe essere simile a quello riportato nell'esempio seguente:

      AD_PASSWORD=<password> ./create-sql-keytab.sh --realm CONTOSO.LOCAL --account sqlmi-account --port 31433 --dns-name sqlmi.contoso.local --keytab-file sqlmi.keytab --secret-name sqlmi-keytab-secret --secret-namespace sqlmi-ns
      
    4. Eseguire il comando seguente per verificare la correttezza del keytab:

      klist -kte <keytab file>
      
  7. Distribuire il segreto Kubernetes per il keytab: per distribuire il segreto, utilizzare il file di specifica del segreto Kubernetes creato nel passaggio precedente.

    Il file di specifica è simile all'esempio riportato di seguito:

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: <secret name>
      namespace: <secret namespace>
    data:
      keytab: <keytab content in Base64>
    

    Per distribuire il segreto Kubernetes, eseguire questo comando:

    kubectl apply -f <file>
    

    Il comando potrebbe essere simile all'esempio riportato di seguito:

    kubectl apply -f sqlmi-keytab-secret.yaml
    

Impostare le proprietà per l'autenticazione di Active Directory

Per distribuire l'Istanza gestita di SQL abilitata da Azure Arc per l'autenticazione di Active Directory di Azure Arc, aggiornare il file delle specifiche di distribuzione per fare riferimento all'istanza di Active Directory Connector da usare. Facendo riferimento ad Active Directory Connector nel file delle specifiche, SQL viene configurato automaticamente per l'autenticazione di Active Directory.

Per supportare l'autenticazione di Active Directory in SQL in modalità keytab gestita dal cliente, impostare le proprietà seguenti nel file di specifica della distribuzione. Alcune proprietà sono obbligatorie, mentre alcune sono facoltative.

Richiesto

  • spec.security.activeDirectory.connector.name: il nome della risorsa personalizzata preesistente di Active Directory Connector da aggiungere per l'autenticazione di Active Directory. Se si immette un valore per questa proprietà, viene implementata l'autenticazione di Active Directory.
  • spec.security.activeDirectory.accountName: il nome dell'account Active Directory per l'Istanza gestita di SQL.
  • spec.security.activeDirectory.keytabSecret: il nome del segreto Kubernetes che ospita il file keytab creato in precedenza per gli utenti. Questo segreto deve trovarsi nello stesso spazio dei nomi dell'istanza gestita. Questo parametro è obbligatorio solo per la distribuzione di Active Directory in modalità keytab gestita dal cliente.
  • spec.services.primary.dnsName: immettere un nome DNS per l'endpoint SQL primario.
  • spec.services.primary.port: immettere un numero di porta per l'endpoint SQL primario.

Facoltativo

  • spec.security.activeDirectory.connector.namespace: lo spazio dei nomi Kubernetes del preesistente Active Directory Connector da aggiungere per l'autenticazione di Active Directory. Se non si immette un valore, verrà utilizzato lo spazio dei nomi SQL.
  • spec.services.readableSecondaries.dnsName: immettere un nome DNS per l'endpoint SQL secondario.
  • spec.services.readableSecondaries.port: immettere un numero di porta per l'endpoint SQL secondario.

Preparare il file delle specifiche di distribuzione

Successivamente, preparare un file delle specifiche YAML per distribuire l'Istanza gestita di SQL. Per la modalità che viene utilizzata, immettere i valori di distribuzione nel file delle specifiche.

Nota

Nel file delle specifiche per entrambe le modalità, il valore admin-login-secret nell'esempio YAML fornisce l'autenticazione di base. È possibile usare il valore del parametro per accedere all'istanza gestita e quindi creare gli ID di accesso per utenti e gruppi di Active Directory. Per altre informazioni, vedere Connettersi all'Istanza gestita di SQL integrata in Active Directory abilitata da Azure Arc.

Nell'esempio seguente è illustrato un file delle specifiche per la modalità keytab gestita dal cliente:

apiVersion: v1
data:
  password: <your Base64-encoded password>
  username: <your Base64-encoded username>
kind: Secret
metadata:
  name: admin-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v3
kind: SqlManagedInstance
metadata:
  name: <name>
  namespace: <namespace>
spec:
  backup:
    retentionPeriodInDays: 7
  dev: false
  tier: GeneralPurpose
  forceHA: "true"
  licenseType: LicenseIncluded
  replicas: 1
  security:
    adminLoginSecret: admin-login-secret
    activeDirectory:
      connector:
        name: <Active Directory connector name>
        namespace: <Active Directory connector namespace>
      accountName: <Active Directory account name>
      keytabSecret: <keytab secret name>
  services:
    primary:
      type: LoadBalancer
      dnsName: <primary endpoint DNS name>
      port: <primary endpoint port number>
    readableSecondaries:
      type: LoadBalancer
      dnsName: <secondary endpoint DNS name>
      port: <secondary endpoint port number>
  storage:
    data:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi
    logs:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi

Distribuire l'istanza gestita

Distribuire l'istanza gestita usando il file di specifica YAML preparato in precedenza, sia per la modalità keytab gestita dal cliente, sia per la modalità keytab gestita dal sistema:

  1. Salvare il file. Nell'esempio riportato nel passaggio seguente si usa sqlmi.yaml come nome del file di specifica, ma può essere scelto qualsiasi nome file.

  2. Eseguire il comando seguente per distribuire l'istanza usando la specifica:

    kubectl apply -f <specification file name>
    

    Il comando potrebbe essere simile a quello riportato nell'esempio seguente:

    kubectl apply -f sqlmi.yaml