Freigeben über

Bereitstellen einer in Active Directory integrierten Instanz von SQL Managed Instance mit Azure Arc-Unterstützung

  • Artikel

In diesem Artikel erfahren Sie, wie Sie SQL Managed Instance mit Azure Arc-Unterstützung mit Active Directory-Authentifizierung bereitstellen.

Voraussetzungen

Stellen Sie sicher, dass Sie über Folgendes verfügen, bevor Sie mit der Bereitstellung von SQL Managed Instance beginnen:

Anforderungen an den Connector

Der Active Directory-Connector mit kundenseitig verwalteter Schlüsseltabelle und der Active Directory-Connector mit systemseitig verwalteter Schlüsseltabelle sind unterschiedliche Bereitstellungsmodi mit verschiedenen Anforderungen und Schritten. Für jeden Modus gelten während der Bereitstellung spezifische Anforderungen. Wählen Sie die Registerkarte für den von Ihnen verwendeten Connector aus.

Für eine Active Directory-Bereitstellung im Modus mit kundenseitig verwalteter Schlüsseltabelle müssen Sie Folgendes angeben:

  • Ein Active Directory-Benutzerkonto für SQL
  • Dienstprinzipalnamen (Service Principal Name, SPN) unter dem Benutzerkonto
  • DNS-A-Eintrag (Weiterleiten) für den primären Endpunkt von SQL (und optional einen sekundären Endpunkt)

Vorbereiten der Bereitstellung

Führen Sie je nach Bereitstellungsmodus die folgenden Schritte aus, um die Bereitstellung von SQL Managed Instance vorzubereiten.

So bereiten Sie die Bereitstellung im Modus mit kundenseitig verwalteter Schlüsseltabelle vor:

  1. Geben Sie einen DNS-Namen für die SQL-Endpunkte an: Wählen Sie eindeutige DNS-Namen für die SQL-Endpunkte aus, mit denen Clients von außerhalb des Kubernetes-Clusters eine Verbindung herstellen.

    • Die DNS-Namen sollten sich in der Active Directory-Domäne oder deren Nachfolgerdomänen befinden.
    • In den Beispielen in diesem Artikel wird sqlmi-primary.contoso.local für den primären DNS-Namen und sqlmi-secondary.contoso.local für den sekundären DNS-Namen verwendet.

  2. Geben Sie die Portnummern für die SQL-Endpunkte an: Geben Sie eine Portnummer für jeden der SQL-Endpunkte ein.

    • Die Portnummern müssen im zulässigen Bereich der Portnummern für Ihren Kubernetes-Cluster liegen.
    • In den Beispielen in diesem Artikel wird 31433 für die primäre Portnummer und 31434 für die sekundäre Portnummer verwendet.

  3. Erstellen Sie ein Active Directory-Konto für die verwaltete Instanz: Wählen Sie einen Namen für das Active Directory-Konto aus, das Ihre verwaltete Instanz darstellt.

    • Der Name muss in der Active Directory-Domäne eindeutig sein.
    • In den Beispielen in diesem Artikel wird sqlmi-account als Name des Active Directory-Kontos verwendet.

    So erstellen Sie das Konto:

    1. Öffnen Sie auf dem Domänencontroller das Tool „Active Directory-Benutzer und -Computer“. Erstellen Sie ein Konto, das die verwaltete Instanz darstellt.
    2. Geben Sie ein Kontokennwort ein, das der Kennwortrichtlinie der Active Directory-Domäne entspricht. Dieses Kennwort verwenden Sie in einigen der Schritte in den nächsten Abschnitten.
    3. Stellen Sie sicher, dass das Konto aktiviert ist. Für das Konto sind keine besonderen Berechtigungen erforderlich.

  4. Erstellen Sie DNS-Einträge für die SQL-Endpunkte auf den Active Directory-DNS-Servern: Erstellen Sie auf einem der Active Directory-DNS-Server A-Einträge (Forward-Lookup-Einträge) für den DNS-Namen, den Sie in Schritt 1 ausgewählt haben.

    • Die DNS-Einträge sollten auf die IP-Adresse verweisen, an der der SQL-Endpunkt auf Verbindungen von außerhalb des Kubernetes-Clusters lauscht.
    • Sie müssen keine PTR-Zeigereinträge (Reverse-Lookup-Einträge) in Verbindung mit den A-Einträgen erstellen.

  5. Erstellen Sie SPNs: Damit SQL die Active Directory-Authentifizierung für die SQL-Endpunkte akzeptieren kann, müssen Sie in dem Konto, das Sie im vorherigen Schritt erstellt haben, zwei SPNs registrieren. Zwei SPNs müssen für den primären Endpunkt registriert werden. Wenn Sie die Active Directory-Authentifizierung für den sekundären Endpunkt verwenden möchten, müssen die SPNs auch für den sekundären Endpunkt registriert werden.

    So erstellen und registrieren Sie SPNs:

    1. Verwenden Sie das folgende Format, um die SPNs zu erstellen:

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

    2. Führen Sie zum Registrieren der SPNs die folgenden Befehle auf einem der Domänencontroller aus:

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

      Ihre Befehle können wie im folgenden Beispiel gezeigt aussehen:

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

    3. Wenn Sie die Active Directory-Authentifizierung für den sekundären Endpunkt verwenden möchten, fügen Sie mithilfe derselben Befehle SPNs für den sekundären Endpunkt hinzu:

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

      Ihre Befehle können wie im folgenden Beispiel gezeigt aussehen:

      setspn -S MSSQLSvc/sqlmi-secondary.contoso.local sqlmi-account
setspn -S MSSQLSvc/sqlmi-secondary.contoso.local:31434 sqlmi-account

  6. Generieren Sie eine Schlüsseltabellendatei mit Einträgen für das Konto und die SPNs: Damit SQL sich bei Active Directory authentifizieren und die Authentifizierung von Active Directory-Benutzern akzeptieren kann, stellen Sie mithilfe eines Kubernetes-Geheimnisses eine Schlüsseltabellendatei bereit.

    • Die Schlüsseltabellendatei enthält verschlüsselte Einträge für das Active Directory-Konto, das für die verwaltete Instanz und die SPNs generiert wurde.

    • SQL Server verwendet diese Datei als Anmeldeinformationen für Active Directory.

    • Zum Generieren einer Schlüsseltabellendatei stehen Ihnen mehrere Tools zur Verfügung:

      • adutil: Verfügbar für Linux (siehe Einführung in adutil)
      • ktutil: Verfügbar unter Linux
      • ktpass: Verfügbar unter Windows
      • Benutzerdefinierte Skripts

    So generieren Sie die Schlüsseltabellendatei speziell für die verwaltete Instanz:

    1. Verwenden Sie eines der folgenden benutzerdefinierten Skripts:

      Die Skripts akzeptieren mehrere Parameter und generieren eine Schlüsseltabellendatei sowie eine YAML-Spezifikationsdatei für das Kubernetes-Geheimnis, das die Schlüsseltabelle enthält.

    2. Ersetzen Sie in Ihrem Skript die Parameterwerte durch Werte für Ihre Bereitstellung der verwalteten Instanz.

      Verwenden Sie für die Eingabeparameter die folgenden Werte:

      • --realm: Die Active Directory-Domäne in Großschreibung. Beispiel: CONTOSO.LOCAL
      • --account: Das Active Directory-Konto, in dem die SPNs registriert sind. Beispiel: sqlmi-account
      • --port: Die Portnummer des primären SQL-Endpunkts. Beispiel: 31433
      • --dns-name: Der DNS-Name für den primären SQL-Endpunkt.
      • --keytab-file: Der Pfad zur Schlüsseltabellendatei.
      • --secret-name Der Name des Schlüsseltabellengeheimnisses, für das eine Spezifikation generiert werden soll.
      • --secret-namespace: Der Kubernetes-Namespace, der das Schlüsseltabellengeheimnis enthält.
      • --secondary-port: Die Portnummer des sekundären SQL-Endpunkts (optional). Beispiel: 31434
      • --secondary-dns-name: Der DNS-Name für den sekundären SQL-Endpunkt (optional).

      Wählen Sie einen Namen für das Kubernetes-Geheimnis aus, das die Schlüsseltabelle hostet. Verwenden Sie den Namespace, in dem die verwaltete Instanz bereitgestellt wird.

    3. Führen Sie den folgenden Befehl aus, um eine Schlüsseltabelle zu erstellen:

      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>

      Ihr Befehl kann wie im folgenden Beispiel gezeigt aussehen:

      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. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass die Schlüsseltabellendatei korrekt ist:

      klist -kte <keytab file>

  7. Stellen Sie das Kubernetes-Geheimnis für die Schlüsseltabelle bereit: Verwenden Sie die im vorherigen Schritt erstellte Spezifikationsdatei des Kubernetes-Geheimnisses, um das Geheimnis bereitzustellen.

    Die Spezifikationsdatei sieht in etwa wie folgt aus:

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

    Führen Sie zum Bereitstellen des Kubernetes-Geheimnisses den folgenden Befehl aus:

    kubectl apply -f <file>

    Ihr Befehl könnte wie dieses Beispiel aussehen:

    kubectl apply -f sqlmi-keytab-secret.yaml

Festlegen der Eigenschaften für die Active Directory-Authentifizierung

Um eine von Azure Arc aktivierte verwaltete SQL-Instanz für die Azure Arc Active Directory-Authentifizierung bereitzustellen, aktualisieren Sie Ihre Bereitstellungsspezifikationsdatei, um auf die zu verwendende Active Directory-Connector-Instanz zu verweisen. Durch den Verweis auf den Active Directory-Connector in der SQL-Spezifikationsdatei wird SQL automatisch für die Active Directory-Authentifizierung eingerichtet.

Wenn Sie die Active Directory-Authentifizierung für SQL im Modus mit kundenseitig verwalteter Schlüsseltabelle unterstützen möchten, legen Sie die folgenden Eigenschaften in der Spezifikationsdatei für Ihre Bereitstellung fest. Einige Eigenschaften sind erforderlich, andere optional.

Erforderlich

  • spec.security.activeDirectory.connector.name: Der Name der bereits vorhandenen benutzerdefinierten Active Directory-Connectorressource, die für die Active Directory-Authentifizierung eingebunden werden soll. Wenn Sie einen Wert für diese Eigenschaft eingeben, wird die Active Directory-Authentifizierung implementiert.
  • spec.security.activeDirectory.accountName: Der Name des Active Directory-Kontos für die verwaltete Instanz.
  • spec.security.activeDirectory.keytabSecret: Der Name des Kubernetes-Geheimnisses, das die vorab erstellte Schlüsseltabellendatei für Benutzer hostet. Dieses Geheimnis muss sich im gleichen Namespace wie die verwaltete Instanz befinden. Dieser Parameter ist nur für die Active Directory-Bereitstellung im Modus mit kundenseitig verwalteter Schlüsseltabelle erforderlich.
  • spec.services.primary.dnsName: Geben Sie einen DNS-Namen für den primären SQL-Endpunkt ein.
  • spec.services.primary.port: Geben Sie eine Portnummer für den primären SQL-Endpunkt ein.

Optional

  • spec.security.activeDirectory.connector.namespace: Der Kubernetes-Namespace des bereits vorhandenen Active Directory-Connectors, der für die Active Directory-Authentifizierung eingebunden werden soll. Wenn Sie keinen Wert eingeben, wird der SQL-Namespace verwendet.
  • spec.services.readableSecondaries.dnsName: Geben Sie einen DNS-Namen für den sekundären SQL-Endpunkt ein.
  • spec.services.readableSecondaries.port: Geben Sie eine Portnummer für den sekundären SQL-Endpunkt ein.

Vorbereiten der Spezifikationsdatei für Ihre Bereitstellung

Bereiten Sie als Nächstes eine YAML-Spezifikationsdatei vor, um SQL Managed Instance bereitzustellen. Geben Sie in der Spezifikationsdatei die Bereitstellungswerte für den von Ihnen verwendeten Modus ein.

Hinweis

In der Spezifikationsdatei für beide Modi wird mit dem Wert admin-login-secret im YAML-Beispiel die Standardauthentifizierung angegeben. Sie können den Parameterwert verwenden, um sich bei der verwalteten Instanz anzumelden, und dann Anmeldungen für Active Directory-Benutzer und -Gruppen erstellen. Weitere Informationen finden Sie unter Verbindung zu Active Directory-integrierten verwalteten SQL-Instanz, die von Azure Arc aktiviert wurden.

Das folgende Beispiel zeigt eine Spezifikationsdatei für den Modus mit kundenseitig verwalteter Schlüsseltabelle:

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

Bereitstellen der verwalteten Instanz

Stellen Sie sowohl für den Modus mit kundenseitig verwalteter Schlüsseltabelle als auch den Modus mit systemseitig verwalteter Schlüsseltabelle die verwaltete Instanz mithilfe der vorbereiteten YAML-Spezifikationsdatei bereit:

  1. Speichern Sie die Datei. Im Beispiel im nächsten Schritt wird sqlmi.yaml als Spezifikationsdateiname verwendet, Sie können jedoch einen beliebigen Dateinamen auswählen.

  2. Führen Sie den folgenden Befehl aus, um die Instanz mithilfe der Spezifikation bereitzustellen:

    kubectl apply -f <specification file name>

    Ihr Befehl kann wie im folgenden Beispiel gezeigt aussehen:

    kubectl apply -f sqlmi.yaml

Zugehöriger Inhalt