Freigeben über

Verwenden des einmaligen Anmeldens von Active Directory für die sichere Verbindung mit dem Kubernetes-API-Server in AKS, die von Azure Arc aktiviert sind

  • Artikel

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

Sie können eine sichere Verbindung mit Ihrem Kubernetes-API-Server in AKS erstellen, die von Arc mit SSO-Anmeldeinformationen (Single Sign-On, Einmaliges Anmelden) (Single Sign-On, SSO) von Arc aktiviert sind.

Übersicht über AD in AKS aktiviert von Arc

Ohne Active Directory-Authentifizierung müssen Sie sich auf eine zertifikatbasierte Kubeconfig-Datei verlassen, wenn Sie über den Befehl eine Verbindung mit dem kubectl API-Server herstellen. Die KUBECONFIG-Datei enthält Geheimnisse, z. B. private Schlüssel und Zertifikate, die sorgfältig verteilt werden müssen. Dies kann ein erhebliches Sicherheitsrisiko darstellen.

Als Alternative zur Verwendung von zertifikatbasiertem Kubeconfig können Sie AD-SSO-Anmeldeinformationen als sichere Möglichkeit zum Herstellen einer Verbindung mit dem API-Server verwenden. Mit der AD-Integration in AKS Arc können Benutzer auf einem Computer, der einer Windows-Domäne beigetreten ist, über kubectl ihre SSO-Anmeldeinformationen eine Verbindung mit dem API-Server herstellen. Dadurch entfällt die Notwendigkeit, zertifikatbasierte KUBECONFIG-Dateien zu verwalten und zu verteilen, die private Schlüssel enthalten.

Bei der AD-Integration wird KUBECONFIG von AD verwendet, die sich von den zertifikatbasierten KUBECONFIG-Dateien unterscheidet und keine Geheimnisse enthält. Die zertifikatbasierte KUBECONFIG-Datei kann jedoch für Sicherungszwecke verwendet werden, z. B. für Problembehandlung, wenn beim Herstellen einer Verbindung mit Active Directory-Anmeldeinformationen Probleme auftreten.

Ein weiterer Sicherheitsvorteil bei der AD-Integration besteht darin, dass Benutzer und Gruppen als Sicherheits-IDs (SIDs) gespeichert werden. Im Gegensatz zu Gruppennamen sind SIDs unveränderlich und eindeutig und stellen daher keine Namenskonflikte dar.

Hinweis

Ad SSO-Konnektivität wird nur für Workloadcluster unterstützt.

Hinweis

Die Verwendung geschachtelter AD-Gruppen (erstellen einer AD-Gruppe innerhalb einer anderen AD-Gruppe) wird nicht unterstützt.

Dieser Artikel führt Sie durch die Schritte zum Einrichten von Active Directory als Identitätsanbieter und zum Aktivieren von SSO über kubectl:

  • Erstellen Sie das AD-Konto für den API-Server, und erstellen Sie dann die KEYTAB-Datei, die dem Konto zugeordnet ist. Weitere Informationen finden Sie unter Erstellen von AD-Authentifizierung mithilfe der KEYTAB-Datei, um das AD-Konto zu erstellen und die KEYTAB-Datei zu generieren.
  • Verwenden Sie die KEYTAB-Datei, um AD-Authentifizierung auf dem Kubernetes-Cluster zu installieren. Im Rahmen dieses Schritts wird automatisch eine Standardkonfiguration von rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC) erstellt.
  • Konvertieren Sie Gruppennamen in SIDs beim Erstellen oder Bearbeiten von RBAC-Konfigurationen und umgekehrt. Anweisungen dazu finden Sie unter Erstellen und Aktualisieren der Rollenbindung der AD-Gruppe.

Voraussetzungen

Bevor Sie mit dem Konfigurieren Active Directory-SSO-Anmeldeinformationen beginnen, sollten Sie sicherstellen, dass die folgenden Elemente verfügbar sind:

  • Das neueste Aks-HciI-PowerShell-Modul ist installiert. Wenn Sie es installieren müssen, lesen Sie Herunterladen und Installieren des AksHci-PowerShell-Moduls.

  • Der AKS-Host ist installiert und konfiguriert. Wenn Sie den Host installieren müssen, führen Sie die Schritte zum Konfigurieren Ihrer Bereitstellung aus.

  • Die KEYTAB-Datei kann verwendet werden. Wenn sie nicht verfügbar ist, führen Sie die Schritte zum Erstellen des AD-Kontos für den API-Server und der KEYTAB-Datei aus.

    Hinweis

    Sie sollten die KEYTAB-Datei für einen bestimmten Dienstprinzipalnamen (Service Principal Name, SPN) generieren, und dieser SPN muss dem AD-Konto des API-Servers des Workloadclusters entsprechen. Außerdem müssen Sie sicherstellen, dass derselbe SPN im gesamten AD-Authentifizierungsprozess verwendet wird. Die KEYTAB-Datei muss den Namen current.keytab aufweisen.

  • Für jeden AKS-Workloadcluster steht ein AD-Konto des API-Servers zur Verfügung.

  • Beim Clientcomputer muss es sich um einen in die Domäne eingebundenen Windows-Computer handeln.

Erstellen von AD-Authentifizierung mithilfe der KEYTAB-Datei

Schritt 1: Erstellen des Workloadclusters und Aktivieren von AD-Authentifizierung

Bevor Sie die AD-Authentifizierung installieren, müssen Sie zuerst einen AKS-Workloadcluster erstellen und das AD-Authentifizierungs-Add-On auf dem Cluster aktivieren. Wenn Sie die AD-Authentifizierung beim Erstellen des neuen Clusters nicht aktivieren, können Sie sie später nicht aktivieren.

Öffnen Sie PowerShell als Administrator, und führen Sie folgendes mit dem -enableADAuth Parameter des New-AksHciCluster Befehls aus:

New-AksHciCluster -name mynewcluster1 -enableADAuth

Stellen Sie für jeden Workloadcluster sicher, dass ein AD-Konto des API-Servers verfügbar ist.

Informationen zum Erstellen des Workloadclusters finden Sie unter Erstellen von Kubernetes-Clustern mit Windows PowerShell.

Schritt 2: Installieren von AD-Authentifizierung

Bevor Sie AD-Authentifizierung installieren können, muss der Workloadcluster installiert und AD-Authentifizierung auf dem Cluster aktiviert werden. Verwenden Sie eine der folgenden Optionen, um AD-Authentifizierung zu installieren.

Option 1:

Öffnen Sie PowerShell als Administrator für einen in eine Domäne eingebundenen Azure Local- oder Windows Server-Cluster, und führen Sie den folgenden Befehl aus:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Hinweis

Verwenden Sie für SPN k8s/apiserver@CONTOSO.comdieses Format das Format SPN k8s/apiserver@<realm name>. Geben Sie <realm name> beim ersten Versuch in Großbuchstaben an. Wenn Sie jedoch Probleme mit Großbuchstaben haben, erstellen Sie den SPN mit Kleinbuchstaben. Bei Kerberos muss die Groß-/Kleinschreibung beachtet werden.

Option 2:

Wenn der Clusterhost nicht einer Domäne beigetreten ist, verwenden Sie den Administratorbenutzer- oder Gruppennamen im SID-Format, wie im folgenden Beispiel gezeigt.

Administratorbenutzer:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

Administratorgruppe:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

Informationen zum Ermitteln der SID für das Benutzerkonto finden Sie unter Bestimmen der Benutzer- oder Gruppen-SID.

Bevor Sie mit den nächsten Schritten fortfahren, notieren Sie sich die folgenden Elemente:

  • Stellen Sie sicher, dass die KEYTAB-Datei den Namen current.keytab aufweist.
  • Ersetzen Sie den SPN, der Ihrer Umgebung entspricht.
  • Der -adminGroup Parameter erstellt eine entsprechende Rollenbindung für die angegebene AD-Gruppe mit Clusteradministratorberechtigungen. Ersetzen Sie contoso\bob (wie in Option 1 oben dargestellt) durch die AD-Gruppe oder den Benutzer, die Ihrer Umgebung entspricht.

Schritt 3: Testen des AD-Webhooks und der KEYTAB-Datei

Stellen Sie sicher, dass der AD-Webhook auf dem API-Server ausgeführt wird und die Keytabdatei als Kubernetes-Schlüssel gespeichert ist. Führen Sie die folgenden Schritte aus, um die zertifikatbasierte KUBECONFIG-Datei für den Workloadcluster abzurufen:

  1. Verwenden Sie den folgenden Befehl, um eine zertifikatbasierte KUBECONFIG-Datei abzurufen. Verwenden Sie die Kubeconfig-Datei, um eine Verbindung mit dem Cluster als lokaler Host herzustellen:

    Get-AksHciCredential -name mynewcluster1

  2. Führen Sie kubectl auf dem Server aus, mit dem Sie eine Verbindung hergestellt haben (mit der zertifikatbasierten Kubeconfig-Datei, die Sie zuvor erstellt haben), und überprüfen Sie dann die AD-Webhook-Bereitstellung, um sicherzustellen, dass sie sich im Format ad-auth-webhook-xxxxbefindet:

    kubectl get pods -n=kube-system

  3. Führen kubectl Sie aus, um zu bestätigen, dass die KEYTAB-Datei als Geheimnis bereitgestellt wurde und als Kubernetes-Geheimnis aufgeführt wird:

    kubectl get secrets -n=kube-system

Schritt 4: Erstellen der AD-KUBECONFIG-Datei

Nachdem der AD-Webhook und die KEYTAB-Datei erfolgreich bereitgestellt wurden, erstellen Sie die AD-KUBECONFIG-Datei. Nachdem die Datei erstellt wurde, kopieren Sie die AD-KUBECONFIG-Datei auf den Clientcomputer und verwenden sie für die Authentifizierung beim API-Server. Im Gegensatz zur zertifikatsbasierten KUBECONFIG-Datei ist AD-KUBECONFIG kein Geheimnis und kann sicher als Nur-Text kopiert werden.

Öffnen Sie PowerShell als Administrator, und führen Sie den folgenden Befehl aus:

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

Schritt 5: Kopieren von KUBECONFIG- und anderen Dateien auf den Clientcomputer

Sie sollten die folgenden drei Dateien aus dem AKS-Workloadcluster auf Ihren Clientcomputer kopieren:

  • Kopieren Sie die im vorherigen Schritt erstellte AD-kubeconfig-Datei in „$env:USERPROFILE.kube\config“.

  • Erstellen Sie den Ordnerpfad "c:\adsso ", und kopieren Sie die folgenden Dateien aus dem AKS-Workloadcluster auf Ihren Clientcomputer:

    • Kubectl.exe unter $env:ProgramFiles\AksHci zu c:\adsso.
    • Kubectl-adsso.exe unter $env:ProgramFiles\AksHci zu c:\adsso.

    Hinweis

    Die adsso.exe Datei wird beim Ausführen des Get-AksHciCredential Cmdlets auf dem Server generiert.

Schritt 6: Herstellen einer Verbindung mit dem API-Server über den Clientcomputer

Nachdem Sie die vorherigen Schritte ausgeführt haben, verwenden Sie Ihre SSO-Anmeldeinformationen, um sich bei Ihrem in die Windows-Domäne eingebundenen Clientcomputer anzumelden. Öffnen Sie PowerShell, und versuchen Sie dann, mithilfe von kubectl auf den API-Server zuzugreifen. Wenn der Vorgang erfolgreich abgeschlossen ist, richten Sie AD SSO ordnungsgemäß ein.

Erstellen und Aktualisieren der Rollenbindung der AD-Gruppe

Wie in Schritt 2 erwähnt, wird eine Standardrollenbindung mit Clusteradministratorrechten für den Benutzer und/oder die Gruppe erstellt, der bzw. die während der Installation bereitgestellt wurde. Rollenbindung in Kubernetes definiert die Zugriffsrichtlinien für AD-Gruppen. In diesem Schritt wird beschrieben, wie Sie mithilfe von RBAC neue AD-Gruppenrollenbindungen in Kubernetes erstellen und vorhandene Rollenbindungen bearbeiten. Beispielsweise möchte der Clusteradministrator Benutzern mithilfe von AD-Gruppen zusätzliche Berechtigungen gewähren (wodurch der Prozess effizienter wird). Weitere Informationen zu RBAC finden Sie unter Verwendung der RBAC-Autorisierung.

Wenn Sie andere RBAC-Einträge für AD-Gruppen erstellen oder bearbeiten, sollte der Antragstellername das Präfix "microsoft:activedirectory:CONTOSO\group name " aufweisen. Beachten Sie, dass die Namen einen Domänennamen und ein Präfix enthalten müssen, die in doppelte Anführungszeichen eingeschlossen sind.

Zwei Beispiele:

Beispiel 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob"

Beispiel 2

Das folgende Beispiel zeigt, wie Sie eine benutzerdefinierte Rollen- und Rollenbindung für einen Namespace mit einer AD-Gruppe erstellen. Im Beispiel SREGroup handelt es sich um eine bereits vorhandene Gruppe im Contoso Active Directory. Wenn Benutzer der AD-Gruppe hinzugefügt werden, werden ihnen sofort Berechtigungen erteilt.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup"

Bevor Sie die YAML-Datei anwenden, sollten die Gruppen- und Benutzernamen immer mithilfe des Befehls in SIDs konvertiert werden:

kubectl-adsso nametosid <rbac.yml>

Um eine vorhandene RBAC zu aktualisieren, können Sie die SID auch in einen benutzerfreundlichen Gruppennamen konvertieren, bevor Sie Änderungen vornehmen. Verwenden Sie zum Konvertieren der SID den folgenden Befehl:

kubectl-adsso sidtoname <rbac.yml>

Ändern des AD-Kontokennworts, das dem Konto des API-Servers zugeordnet ist

Wenn das Kennwort für das Konto des API-Servers geändert wird, müssen Sie das Add-On für AD-Authentifizierung deinstallieren und mithilfe der aktualisierten aktuellen und vorherigen KEYTAB-Dateien neu installieren.

Jedes Mal, wenn Sie das Kennwort ändern, müssen Sie die aktuelle KEYTAB-Datei (current.keytab) in previous.keytab umbenennen. Stellen Sie dann sicher, dass Sie das neue Kennwort current.keytab nennen.

Wichtig

Die Dateien müssen den Namen current.keytab bzw. previous.keytab aufweisen. Die vorhandenen Rollenbindungen sind von dieser Änderung nicht betroffen.

Deinstallieren und erneutes Installieren von AD-Authentifizierung

Möglicherweise möchten Sie AD SSO erneut installieren, wenn das Konto für den API-Server geändert wird, wenn das Kennwort aktualisiert wird oder um einen Fehler zu beheben.

Um AD-Authentifizierung zu deinstallieren, öffnen Sie PowerShell als Administrator, und führen Sie den folgenden Befehl aus:

Uninstall-AksHciAdAuth -name mynewcluster1

Um AD-Authentifizierung erneut zu deinstallieren, öffnen Sie PowerShell als Administrator, und führen Sie den folgenden Befehl aus:

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Hinweis

Um Ausfallzeiten zu vermeiden, wenn die Clients Tickets zwischengespeichert haben, ist der -previousKeytab Parameter nur erforderlich, wenn Sie das Kennwort ändern.

Erstellen des AD-Kontos des API-Servers und der Keytabdatei

Zwei Schritte sind an der Erstellung der AD-Konto- und Keytabdatei beteiligt. Erstellen Sie zunächst ein neues AD-Konto/einen neuen BENUTZER für den API-Server mit dem Dienstprinzipalnamen (SERVICE Principal Name, SPN), und erstellen Sie dann eine Keytabdatei für das AD-Konto.

Schritt 1: Erstellen eines neuen AD-Kontos oder -Benutzers für den API-Server

Verwenden Sie den PowerShell-Befehl New-ADUser, um ein neues AD-Konto bzw. einen neuen -Benutzer mit dem SPN zu erstellen. Hier sehen Sie ein Beispiel:

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

Schritt 2: Erstellen der KEYTAB-Datei für das AD-Konto

Verwenden Sie zum Erstellen der Keytabdatei den Windows-Befehl "ktpass ".

Das folgende Beispiel zeigt die Verwendung von ktpass:

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Hinweis

Wenn der Fehler "DsCrackNames" 0x2 im Namenseintrag zurückgegeben wird, stellen Sie sicher, dass sich der Parameter in /mapuser Form mapuser DOMAIN\userbefindet, wobei DOMAIN die Ausgabe von Echo %userdomain%ist.

Bestimmen der Benutzer- oder Gruppen-SID

Verwenden Sie eine der folgenden beiden Optionen, um die SID für Ihr Konto oder andere Konten zu finden:

  • Um die sid zu finden, die Ihrem Konto zugeordnet ist, geben Sie in einer Eingabeaufforderung Ihres Startverzeichnisses den folgenden Befehl ein:

    whoami /user

  • Um die SID zu finden, die einem anderen Konto zugeordnet ist, öffnen Sie PowerShell als Administrator, und führen Sie den folgenden Befehl aus:

    (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

Behandeln von Problemen mit Zertifikaten

Der Webhook und der API-Server verwenden Zertifikate, um die TLS-Verbindung gegenseitig zu überprüfen. Dieses Zertifikat läuft nach 500 Tagen ab. Um zu überprüfen, ob das Zertifikat abgelaufen ist, sehen Sie sich die Protokolle in einem ad-auth-webhook-Container an:

kubectl logs ad-auth-webhook-xxx

Wenn Zertifikatvalidierungsfehler angezeigt werden, führen Sie die Schritte zum Deinstallieren und erneuten Installieren des Webhooks aus und rufen neue Zertifikate ab.

Bewährte Methoden und Bereinigungen

  • Verwenden Sie ein eindeutiges Konto für jeden Cluster.
  • Verwenden Sie das Kennwort für das API-Serverkonto nicht clusterübergreifend wieder.
  • Löschen Sie die lokale Kopie der Schlüsseltabellendatei (keytab), sobald Sie den Cluster erstellen, und überprüfen Sie, ob die SSO-Anmeldeinformationen funktionieren.
  • Löschen Sie den Active Directory-Benutzer, der für den API-Server erstellt wurde. Weitere Informationen finden Sie unter Remove-ADUser.

Nächste Schritte

In diesem Leitfaden mit Vorgehensweisen haben Sie erfahren, wie Sie AD-Authentifizierung konfigurieren, um eine sichere Verbindung mit dem API-Server mit SSO-Anmeldeinformationen herzustellen. Als Nächstes haben Sie folgende Möglichkeiten: