Konfigurieren von gruppenverwalteten Dienstkonten (group Managed Service Accounts, gMSA) für Windows Container mit Azure Kubernetes Service in Azure Stack HCI und Windows Server

Artikel
05/01/2024

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

Zur Verwendung der AD-Authentifizierung können Sie gruppenverwaltete Dienstkonten (group Managed Service Accounts, gMSA) für Windows-Container so konfigurieren, dass sie mit einem nicht in eine Domäne eingebundenen Host ausgeführt werden. Ein gruppenverwaltetes Dienstkonto ist eine besondere Art von Dienstkonto. Es wurde mit Windows Server 2012 eingeführt, um mehreren Computern zu ermöglichen, eine Identität gemeinsam zu nutzen, ohne das Passwort zu kennen. Windows-Container können nicht in eine Domäne eingebunden werden, aber viele Windows-Anwendungen, die in Windows-Containern ausgeführt werden, benötigen weiterhin die AD-Authentifizierung.

Hinweis

Erfahren Sie hier, wie die Kubernetes-Community die Verwendung von gMSA mit Windows-Containern unterstützt: Konfigurieren von gMSA.

Die Architektur von gMSA für Container mit einem nicht in eine Domäne eingebundenen Host

gMSA für Container mit einem nicht in eine Domäne eingebundenen Host verwendet eine portable Benutzeridentität anstelle einer Hostidentität, um gMSA-Anmeldeinformationen abzurufen. Daher ist das manuelle Verknüpfen von Windows-Workerknoten mit einer Domäne nicht mehr erforderlich. Die Benutzeridentität wird als Geheimnis in Kubernetes gespeichert. Das folgende Diagramm zeigt den Prozess zum Konfigurieren von gMSA für Container mit einem nicht in die Domäne eingebundenen Host:

Diagramm von gruppenverwalteten Dienstkonten, Version 2

gMSA für Container mit einem nicht in eine Domäne eingebundenen Host bietet die Flexibilität, Container mit gMSA zu erstellen, ohne den Hostknoten in eine Domäne einzubinden. Ab Windows Server 2019 wird ccg.exe unterstützt, wodurch ein Plug-In-Mechanismus gMSA-Anmeldeinformationen aus Active Directory abrufen kann. Sie können diese Identität verwenden, um den Container zu starten. Weitere Informationen zu ccg.exe finden Sie in der ICcgDomainAuthCredentials-Schnittstelle.

Der Vergleich von gMSA für Container mit einem nicht in eine Domäne eingebundenen Host und einem in eine Domäne eingebundenen Host

Als gMSA ursprünglich eingeführt wurde, musste der Containerhost in eine Domäne eingebunden sein. Das manuelle Einbinden von Windows-Workerknoten in eine Domäne führte zu einem erheblichen Mehraufwand. Diese Einschränkung wurde mit gMSA für Container mit einem nicht in die Domäne eingebundenen Host behoben, sodass Benutzer jetzt gMSA mit nicht in die Domäne eingebundenen Hosts verwenden können. Weitere Verbesserungen an gMSA umfassen die folgenden Features:

Eliminieren der Notwendigkeit, Windows-Workerknoten manuell in eine Domäne einzubinden, was einen großen Mehraufwand bedeutete. Bei Skalierungsszenarien vereinfacht dies den Prozess.
In Rolling-Update-Szenarien müssen Benutzer den Knoten nicht länger erneut in eine Domäne einbinden.
Ein einfacheres Verfahren zum Verwalten von Workerknoten-Computerkonten für den Abruf von gMSA-Dienstkontokennwörtern.
Ein weniger komplizierter End-to-End-Prozess zum Konfigurieren von gMSA mit Kubernetes.

Bevor Sie beginnen

Um einen Windows-Container mit einem gruppenverwalteten Dienstkonto auszuführen, benötigen Sie die folgenden Voraussetzungen:

Eine Active Directory-Domäne mit mindestens einem Domänencontroller mit Windows Server 2012 oder höher. Es gibt keine Gesamtstruktur- oder Domänenfunktionsebenenanforderungen für die Verwendung von gMSAs, aber nur Domänencontroller, auf denen Windows Server 2012 oder höher ausgeführt werden, können gMSA-Kennwörter verteilen. Weitere Informationen finden Sie unter Active Directory-Anforderungen für gMSAs.
Berechtigung zum Erstellen eines gMSA-Kontos. Um ein gMSA-Konto zu erstellen, müssen Sie Domänenadministrator sein oder ein Konto verwenden, das über Berechtigungen zum Erstellen von msDS-GroupManagedServiceAccount-Objekten verfügt.
Greifen Sie auf das Internet zu, um das CredentialSpec-PowerShell-Modul herunterzuladen. Wenn Sie in einer nicht verbundenen Umgebung arbeiten, können Sie das Modul auf einem Computer mit Internetzugang speichern und es auf Ihren Entwicklungscomputer oder Containerhost kopieren.
Um sicherzustellen, dass die gMSA- und AD-Authentifizierung funktioniert, vergewissern Sie sich, dass die Azure Stack HCI- und Windows Server-Clusterknoten so konfiguriert sind, dass sie ihre Zeit mit einem Domänencontroller oder einer anderen Zeitquelle synchronisieren. Sie sollten außerdem sicherstellen, dass Hyper-V so konfiguriert ist, dass die Zeit mit allen virtuellen Computern synchronisiert wird.

Vorbereiten des gMSA auf dem Domänencontroller

Führen Sie die folgenden Schritte aus, um die gMSA auf dem Domänencontroller vorzubereiten:

Bereiten Sie auf dem Domänencontroller Active Directory vor, und erstellen Sie das gMSA-Konto.
Erstellen Sie ein Domänenbenutzerkonto. Diese Benutzerkonto-/Kennwortanmeldeinformationen werden als Kubernetes-Geheimnis gespeichert und zum Abrufen des gMSA-Kennworts verwendet.

Führen Sie den folgenden New-ADServiceAccount-PowerShell-Befehl aus, um ein gMSA-Konto zu erstellen und die Berechtigung zum Lesen des Kennworts für das in Schritt 2 erstellte gMSA-Konto zu erteilen:

 New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>", "host/<gmsa account name>.<domain name>.com" -PrincipalsAllowedToRetrieveManagedPassword <username you created earlier>

Geben Sie für -PrincipalsAllowedToRetrieveManagedPasswordden Domänenbenutzernamen an, den Sie zuvor erstellt haben, wie im folgenden Beispiel gezeigt:

New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"

Vorbereiten der JSON-Datei mit der gMSA-Anmeldeinformationsspezifikation

Führen Sie zum Vorbereiten der JSON-Datei mit der gMSA Anmeldeinformationsspezifikation die Schritte zum Erstellen einer Anmeldeinformationsspezifikation aus.

Konfigurieren von gMSA für Windows-Pods und -Container im Cluster

Die Kubernetes-Community unterstützt bereits in eine Domäne eingebundene Windows-Workerknoten für gMSA. Zwar müssen Sie in AKS in Azure Stack HCI und Windows Server keinen Windows-Workerknoten in eine Domäne einbinden, doch es gibt andere Konfigurationsschritte. Zu diesen Schritten gehören die Installation des Webhooks, der benutzerdefinierten Ressourcendefinition (CRD) und der Anmeldeinformationsspezifikation sowie das Aktivieren der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC-Rolle). In den folgenden Schritten werden PowerShell-Befehle verwendet, die erstellt wurden, um den Konfigurationsprozess zu vereinfachen.

Bevor Sie die folgenden Schritte ausführen, stellen Sie sicher, dass das AksHci PowerShell-Modul installiert ist und kubectl eine Verbindung mit Ihrem Cluster herstellen kann.

Führen Sie zum Installieren des Webhooks den folgenden Install-AksHcigMSAWebhook-PowerShell-Befehl aus:
```
Install-AksHciGMSAWebhook -Name <cluster name>
```
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Webhook-Pod erfolgreich ausgeführt wird:
```
kubectl get pods -n kube-system | findstr gmsa
```
Es sollte ein Pod mit dem Präfix gMSA-Webhook angezeigt werden, der ausgeführt wird.
Erstellen Sie das geheime Objekt, in dem die Anmeldeinformationen des Active Directory-Benutzers gespeichert sind. Füllen Sie die folgenden Konfigurationsdaten aus, und speichern Sie die Einstellungen in einer Datei namens secret.yaml.
```
apiVersion: v1
kind: Secret
metadata:
   name: <secret-name>
   namespace: <secret under namespace other than the default>
type: Opaque
stringData:
   domain: <FQDN of the domain, for example: akshcitest.com>
   username: <domain user who can retrieve the gMSA password>
   password: <password>
```
Führen Sie dann den folgenden Befehl aus, um das Geheimnisobjekt zu erstellen:
```
kubectl apply -f secret.yaml
```
Hinweis

Wenn Sie ein Geheimnis unter einem anderen Namespace als dem Standardnamespace erstellen, denken Sie daran, den Namespace der Bereitstellung auf denselben Namespace festzulegen.
Verwenden Sie das PowerShell-Cmdlet Add-AksHciGMSACredentialSpec , um die gMSA-CRD zu erstellen, die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) zu aktivieren und die Rolle dann den Dienstkonten zuzuweisen, um eine bestimmte gMSA-Anmeldeinformationsspezifikationsdatei zu verwenden. Diese Schritte werden in diesem Kubernetes-Artikel zum Konfigurieren von gMSA für Windows-Pods und -Containerausführlicher beschrieben.

Verwenden Sie die JSON-Anmeldeinformationsspezifikation als Eingabe für den folgenden PowerShell-Befehl (Parameter mit Sternchen * sind obligatorisch):
```
Add-AksHciGMSACredentialSpec -Name <cluster name>*  
  -credSpecFilePath <path to JSON credspec>* 
  -credSpecName <name for credspec as the k8s GMSACredentialSpec object>* 
  -secretName <name of secret>* 
  -secretNamespace <namespace of secret>  
  -serviceAccount <name of service account to bind to clusterrole>  
  -clusterRoleName <name of clusterrole to use the credspec>*  
  -overwrite 
```
Ein Beispiel finden Sie im folgenden Code:
```
Add-AksHciGMSACredentialSpec -Name mynewcluster 
  -credSpecFilePath .\credspectest.json 
  -credSpecName credspec-mynewcluster 
  -secretName mysecret 
  -clusterRoleName clusterrole-mynewcluster
```

Bereitstellen der Anwendung

Erstellen Sie die YAML-Bereitstellungsdatei mithilfe der folgenden Beispieleinstellungen. Zu den erforderlichen Einträgen gehören serviceAccountName, gmsaCredentialSpecName, volumeMounts und dnsconfig.

Fügen Sie das Dienstkonto hinzu:

serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

Fügen Sie das Objekt für die Anmeldeinformationsspezifikation für hinzu:

securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

Binden Sie das Geheimnis für die Bereitstellung ein:

volumeMounts:
     - name: <volume name>
       mountPath: <vmount path>
       readOnly: true
   volumes:
     - name: <volume name>
       secret:
         secretName: <secret name>
         items:
           - key: username
             path: my-group/my-username

Fügen Sie die IP-Adresse des Domänencontrollers und den Domänennamen unter „dnsConfig“ hinzu:

dnsConfig: 
     nameservers:
       - <IP address for domain controller>
     searches: 
       - <domain>

Überprüfen Sie, ob der Container mit gMSA funktioniert

Nachdem Sie den Container bereitgestellt haben, überprüfen Sie anhand der folgenden Schritte, ob er funktioniert:

Führen Sie den folgenden Befehl aus, um die Container-ID für Ihre Bereitstellung abzurufen:
```
kubectl get pods
```
Öffnen Sie PowerShell, und führen Sie den folgenden Befehl aus:
```
kubectl exec -it <container id> powershell
```
Sobald Sie sich im Container befinden, führen Sie den folgenden Befehl aus:
```
Nltest /parentdomain 
Nltest /sc_verify:<domain> 
```
```
Connection Status = 0 0x0 NERR_Success The command completed successfully. 
```
Diese Ausgabe zeigt, dass der Computer von einem Domänencontroller authentifiziert wurde und ein sicherer Kanal zwischen dem Clientcomputer und dem Domänencontroller vorhanden ist.
Überprüfen Sie, ob der Container ein gültiges Kerberos-Ticket-Granting Ticket (TGT) abrufen kann.
```
klist get krbtgt
```
```
A ticket to krbtgt has been retrieved successfully
```

Bereinigen von gMSA-Einstellungen im Cluster

Wenn Sie die gMSA-Einstellungen bereinigen müssen, nutzen Sie die folgenden Deinstallation-Schritte.

Deinstallieren der Anmeldeinformationsspezifikation

Führen Sie zum Deinstallieren den folgenden Remove-AksHcigMSACredentialSpec-PowerShell-Befehl aus:

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec object name> -clusterRoleName <clusterrole object name> -serviceAccount <serviceaccount object name> -secretNamespace <namespace of the secret object>

Deinstallieren des Webhooks

Führen Sie zum Deinstallieren des Webhooks den folgenden Uninstall-AksHcigMSAWebhook-PowerShell-Befehl aus:

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Freigeben über