Condividi tramite

Distribuire le Istanza gestita di SQL integrate di Active Directory abilitate da Azure Arc

  • Articolo

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

Prerequisiti

Prima di iniziare la distribuzione di Istanza gestita di SQL, assicurarsi di avere questi prerequisiti:

  • Un dominio di Active Directory
  • Un controller dati di Azure Arc distribuito
  • Connettore Active Directory distribuito con keytab gestito dal cliente o keytab gestito dal sistema

requisiti di Connessione or

Il connettore Di Active Directory gestito dal cliente e il connettore di Active Directory gestito dal sistema sono diverse modalità di distribuzione con requisiti e passaggi diversi. Ogni modalità presenta requisiti specifici durante la distribuzione. Selezionare la scheda per il connettore usato.

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

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

Preparare la distribuzione

A seconda della modalità di distribuzione, completare i passaggi seguenti per preparare la distribuzione 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 a cui i client si connetteranno dall'esterno del cluster Kubernetes.

    • I nomi DNS devono trovarsi nel dominio di Active Directory o nei relativi domini discendenti.
    • Gli esempi in questo articolo usano 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 ognuno degli endpoint SQL.

    • I numeri di porta devono trovarsi nell'intervallo accettabile di numeri di porta per il cluster Kubernetes.
    • Gli esempi in questo articolo usano 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 per rappresentare l'istanza gestita.

    • Il nome deve essere univoco nel dominio di Active Directory.
    • Gli esempi in questo articolo usano 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 Active Directory. Questa password verrà usata 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 record A (record di ricerca diretta) per il nome DNS scelto nel passaggio 1.

    • I record DNS devono puntare all'indirizzo IP su cui l'endpoint SQL rimarrà in ascolto per le connessioni dall'esterno del cluster Kubernetes.
    • Non è necessario creare record PTR (Reverse Lookup Pointer) in associazione ai record A.

  5. Creare nomi SPN: per consentire a SQL di accettare l'autenticazione di Active Directory sugli endpoint SQL, è necessario registrare due NOMI SPN nell'account creato nel passaggio precedente. È necessario registrare due NOMI SPN per l'endpoint primario. Se si vuole l'autenticazione di Active Directory per l'endpoint secondario, è necessario registrare anche i nomi SPN per l'endpoint secondario.

    Per creare e registrare nomi SPN:

    1. Usare il formato seguente per creare i nomi SPN:

      MSSQLSvc/<DNS name>
MSSQLSvc/<DNS name>:<port>

    2. In uno dei controller di dominio eseguire i comandi seguenti per registrare i nomi SPN:

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

      I comandi potrebbero essere simili all'esempio seguente:

      setspn -S MSSQLSvc/sqlmi-primary.contoso.local sqlmi-account
setspn -S MSSQLSvc/sqlmi-primary.contoso.local:31433 sqlmi-account

    3. Se si vuole l'autenticazione di Active Directory nell'endpoint secondario, eseguire gli stessi comandi per aggiungere SPN per l'endpoint secondario:

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

      I comandi potrebbero essere simili all'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 SPN: per consentire a SQL di autenticarsi in Active Directory e accettare l'autenticazione da parte degli utenti di Active Directory, fornire un file keytab usando 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 credenziale in Active Directory.

    • È possibile scegliere tra più strumenti per generare un file keytab:

      • adutil: disponibile per Linux (vedere Introduzione ad adutil)
      • ktutil: disponibile in Linux
      • ktpass: disponibile in 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 la scheda chiave.

    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: 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: numero di porta dell'endpoint SQL primario. Esempio: 31433
      • --dns-name: nome DNS per l'endpoint SQL primario.
      • --keytab-file: percorso del file keytab.
      • --secret-name: nome del segreto keytab per cui generare una specifica.
      • --secret-namespace: spazio dei nomi Kubernetes che contiene il segreto keytab.
      • --secondary-port: numero di porta dell'endpoint SQL secondario (facoltativo). Esempio: 31434
      • --secondary-dns-name: nome DNS per l'endpoint SQL secondario (facoltativo).

      Scegliere un nome per il segreto Kubernetes che ospita la scheda chiave. 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 all'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 che il keytab sia corretto:

      klist -kte <keytab file>

  7. Distribuire il segreto Kubernetes per il keytab: usare il file di specifica del segreto Kubernetes creato nel passaggio precedente per distribuire il segreto.

    Il file di specifica è simile a questo esempio:

    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 seguente:

    kubectl apply -f sqlmi-keytab-secret.yaml

Impostare le proprietà per l'autenticazione di Active Directory

Per distribuire Istanza gestita di SQL abilitato dall'autenticazione di Azure Arc per Azure Arc Active Directory, aggiornare il file delle specifiche di distribuzione per fare riferimento all'istanza del connettore Active Directory da usare. Fare riferimento al connettore Active Directory nel file di specifica SQL configura automaticamente SQL 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 delle specifiche di distribuzione. Alcune proprietà sono obbligatorie e alcune sono facoltative.

Richiesto

  • spec.security.activeDirectory.connector.name: nome della risorsa personalizzata del connettore Active Directory preesistente 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: nome dell'account Active Directory per l'istanza gestita.
  • spec.security.activeDirectory.keytabSecret: nome del segreto Kubernetes che ospita il file keytab creato in modo preliminare 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: spazio dei nomi Kubernetes del connettore Di Active Directory preesistente da aggiungere per l'autenticazione di Active Directory. Se non si immette un valore, viene usato 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

Preparare quindi un file di specifica YAML per distribuire Istanza gestita di SQL. Per la modalità usata, immettere i valori di distribuzione nel file di specifica.

Nota

Nel file di specifica per entrambe le modalità, il admin-login-secret valore nell'esempio YAML fornisce l'autenticazione di base. È possibile usare il valore del parametro per accedere all'istanza gestita e quindi creare account di accesso per utenti e gruppi di Active Directory. Per altre informazioni, vedere Connessione alle Istanza gestita di SQL integrate in Active Directory abilitate da Azure Arc.

L'esempio seguente mostra un file di specifica 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

Per la modalità keytab gestita dal cliente e la modalità keytab gestita dal sistema, distribuire l'istanza gestita usando il file YAML di specifica preparato:

  1. Salvare il file. L'esempio nel passaggio successivo usa sqlmi.yaml per il nome del file di specifica, ma è possibile scegliere 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 all'esempio seguente:

    kubectl apply -f sqlmi.yaml

Contenuto correlato