Aktivieren von gruppenverwalteten Dienstkonten (GMSAs) für Ihre Windows Server-Knoten auf Ihrem AKS-Cluster (Azure Kubernetes Service)

Artikel
08/02/2024

Ein gruppenverwaltetes Dienstkonto (GMSA) ist ein verwaltetes Domänenkonto für mehrere Server, das eine automatische Kennwortverwaltung, eine vereinfachte Verwaltung von Dienstprinzipalnamen (Service Principal Name, SPN) sowie die Möglichkeit bietet, die Verwaltung an andere Administrator*innen zu delegieren. Mit Azure Kubernetes Service (AKS) können Sie GMSA auf Ihren Windows Server-Knoten aktivieren, sodass Container, die auf Windows Server-Knoten ausgeführt werden, in GMSA integriert und über GMSA verwaltet werden können.

Voraussetzungen

Kubernetes 1.19 oder höher Informationen zum Überprüfen Ihrer Version finden Sie unter Überprüfen auf verfügbare Upgrades. Informationen zum Durchführen eines Upgrades für Ihre Version finden Sie unter Aktualisieren eines AKS-Clusters.
Azure CLI, Version 2.35.0 oder höher. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.
Aktivierung verwalteter Identitäten auf Ihrem AKS-Cluster.
Berechtigungen zum Erstellen oder Aktualisieren einer Azure Key Vault-Instanz
Berechtigungen zum Konfigurieren von GMSA für Active Directory Domain Services oder lokales Active Directory.
Auf dem Domänencontroller müssen Active Directory-Webdienste aktiviert sein, und der AKS-Cluster muss über Port 9389 erreichbar sein.

Hinweis

Microsoft bietet auch ein speziell entwickeltes PowerShell-Modul zum Konfigurieren von gMSA in AKS. Weitere Informationen finden Sie unter gMSA unter Azure Kubernetes Service.

Konfigurieren eines gruppenverwalteten Dienstkontos auf einem Active Directory-Domänencontroller

Um GMSA mit AKS verwenden zu können, benötigen Sie Benutzeranmeldeinformationen der Standarddomäne, um auf die für Ihren Domänencontroller konfigurierten GMSA-Anmeldeinformationen zugreifen zu können. Informationen zum Konfigurieren von GMSA auf Ihrem Domänencontroller finden Sie unter Erste Schritte mit gruppenverwalteten Dienstkonten. Für die Anmeldeinformationen der Standarddomäne können Sie einen vorhandenen Benutzer verwenden oder einen neuen erstellen. Dieser muss jedoch Zugriff auf die GMSA-Anmeldeinformationen haben.

Wichtig

Sie müssen entweder Active Directory Domain Services oder die lokale Active Directory-Instanz verwenden. Zurzeit können Sie Microsoft Entra ID nicht verwenden, um GMSA mit einem AKS-Cluster zu konfigurieren.

Speichern der Standardbenutzeranmeldeinformationen für die Domäne in Azure Key Vault

Ihr AKS-Cluster verwendet die Standardbenutzeranmeldeinformationen der Domäne, um vom Domänencontroller aus auf die GMSA-Anmeldeinformationen zuzugreifen. Um sicheren Zugriff auf diese Anmeldeinformationen für den AKS-Cluster zu ermöglichen, sollten Sie diese in Azure Key Vault speichern.

Wenn Sie noch keine Azure Key Vault-Instanz verwenden, erstellen Sie eine mit dem Befehl az keyvault create.
```
az keyvault create --resource-group myResourceGroup --name myGMSAVault
```
Verwenden Sie den Befehl az keyvault secret set, um die Benutzeranmeldeinformationen der Standarddomäne als Geheimnis in Ihrem Schlüsseltresor zu speichern. Im folgenden Beispiel werden die Domänenbenutzer-Anmeldeinformationen mit dem Schlüssel GMSADomainUserCred im Schlüsseltresor myGMSAVault gespeichert.
```
az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
```
Hinweis

Stellen Sie sicher, dass Sie den vollqualifizierten Domänennamen für die Domäne verwenden.

Optional: Verwenden eines benutzerdefinierten VNet mit benutzerdefiniertem DNS

Ihr Domänencontroller muss über DNS konfiguriert werden, damit er vom AKS-Cluster erreicht werden kann. Sie können Ihr Netzwerk und DNS außerhalb Ihres AKS-Clusters konfigurieren, damit Ihr Cluster auf den Domänencontroller zugreifen kann. Alternativ können Sie über Azure CNI ein benutzerdefiniertes VNet mit einem benutzerdefinierten DNS in Ihrem AKS-Cluster konfigurieren, um Zugriff auf Ihren Domänencontroller zu ermöglichen. Weitere Informationen finden Sie unter Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS).

Optional: Konfigurieren mehrerer DNS-Server

Wenn Sie in Ihrem AKS-Cluster unter Windows mehrere DNS-Server für über Gruppen verwaltete Dienstkonten konfigurieren möchten, geben Sie nicht --gmsa-dns-server oder v--gmsa-root-domain-name an. Stattdessen können Sie mehrere DNS-Server im VNet hinzufügen, indem Sie Benutzerdefinierter DNS auswählen und die DNS-Server hinzufügen.

Optional: Verwenden Ihrer eigenen Kubelet-Identität für Ihren Cluster

Um dem AKS-Cluster Zugriff auf Ihren Schlüsseltresor zu ermöglichen, benötigt die Kubelet-Identität des Clusters Zugriff auf Ihren Schlüsseltresor. Wenn Sie einen Cluster mit aktivierter verwalteter Identität erstellen, wird standardmäßig automatisch eine Kubelet-Identität erstellt.

Sie können entweder der Identität nach der Clustererstellung Zugriff auf Ihren Schlüsseltresor gewähren oder vor der Clustererstellung Ihre eigene Identität zur Verwendung erstellen, indem Sie die folgenden Schritte ausführen:

Erstellen Sie mithilfe des Befehls az identity create eine Kubelet-Identität.
```
az identity create --name myIdentity --resource-group myResourceGroup
```
Rufen Sie die ID der Identität mithilfe des Befehls az identity list ab, und legen Sie sie auf eine Variable mit dem Namen MANAGED_ID fest.
```
MANAGED_ID=$(az identity list --query "[].id" -o tsv)
```
Erteilen Sie der Identität Zugriff auf Ihren Schlüsseltresor, indem Sie den Befehl az keyvault set-policy ausführen.
```
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
```

Aktivieren von GMSA auf einem neuen AKS-Cluster

Erstellen Sie Administratoranmeldeinformationen, die während der Clustererstellung verwendet werden sollen. Die folgenden Befehle fordern Sie zur Eingabe eines Benutzernamens auf und legen diesen zur Verwendung in einem späteren Befehl auf WINDOWS_USERNAME fest.
```
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
```
Erstellen Sie einen AKS-Cluster mit dem Befehl az aks create und den folgenden Parametern:
- --enable-windows-gmsa: Aktiviert GMSA für den Cluster.
- --gmsa-dns-server: Die IP-Adresse des DNS-Servers.
- --gmsa-root-domain-name: Der Stammdomänenname des DNS-Servers.
```
DNS_SERVER=<IP address of DNS server>
ROOT_DOMAIN_NAME="contoso.com"

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --vm-set-type VirtualMachineScaleSets \
    --network-plugin azure \
    --load-balancer-sku standard \
    --windows-admin-username $WINDOWS_USERNAME \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME \
    --generate-ssh-keys
```
Hinweis
- Wenn Sie ein benutzerdefiniertes VNet verwenden, müssen Sie die VNet-ID mithilfe des Parameters vnet-subnet-id angeben. Möglicherweise müssen Sie je nach Konfiguration auch die Parameter docker-bridge-address, dns-service-ip und service-cidr hinzufügen.
- Wenn Sie Ihre eigene Identität für die Kubelet-Identität erstellt haben, verwenden Sie den assign-kubelet-identity-Parameter, um Ihre Identität anzugeben.
- Wenn Sie die --gmsa-dns-server und --gmsa-root-domain-name-Parameter angeben, wird der kube-system/coredns-ConfigMap eine DNS-Weiterleitungsregel hinzugefügt. Diese Regel leitet die DNS-Anforderungen $ROOT_DOMAIN_NAME von den Pods an die $DNS_SERVER weiter.
```
$ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}
```

Fügen Sie mithilfe des Befehls az aks nodepool add einen Windows Server-Knotenpool hinzu.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --name npwin \
    --node-count 1

Aktivieren von GMSA für einen vorhandenen Cluster

Aktivieren Sie GMSA in einem vorhandenen Cluster mit aktivierten Windows Server-Knoten und verwalteten Identitäten mithilfe des Befehls az aks update.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-windows-gmsa \
    --gmsa-dns-server $DNS_SERVER \
    --gmsa-root-domain-name $ROOT_DOMAIN_NAME

Gewähren des Zugriffs auf Ihren Schlüsseltresor für die Kubelet-Identität

Hinweis

Wenn Sie Ihre eigene Identität für die Kubelet-Identität angegeben haben, überspringen Sie diesen Schritt.

Gewähren Sie Zugriff auf Ihren Schlüsseltresor für die Kubelet-Identität über den Befehl az keyvault set-policy.

MANAGED_ID=$(az aks show -g myResourceGroup -n myAKSCluster --query "identityProfile.kubeletidentity.objectId" -o tsv)
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get

Installieren der GMSA-CRED-Spezifikation

Mit dem Befehl az aks get-credentials können Sie kubectl für die Verbindungsherstellung mit Ihrem Kubernetes-Cluster konfigurieren.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Erstellen Sie eine neue YAML-Datei mit dem Namen gmsa-spec.yaml, und fügen Sie den folgenden YAML-Code ein. Ersetzen Sie die Platzhalter durch Ihre eigenen Werte.

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: aks-gmsa-spec  # This name can be changed, but it will be used as a reference in the pod spec
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: $GMSA_ACCOUNT_USERNAME
      Scope: $NETBIOS_DOMAIN_NAME
    - Name: $GMSA_ACCOUNT_USERNAME
      Scope: $DNS_DOMAIN_NAME
    HostAccountConfig:
      PluginGUID: '{CCC2A336-D7F3-4818-A213-272B7924213E}'
      PortableCcgVersion: "1"
      PluginInput: "ObjectId=$MANAGED_ID;SecretUri=$SECRET_URI"  # SECRET_URI takes the form https://$akvName.vault.azure.net/secrets/$akvSecretName
  CmsPlugins:
 - ActiveDirectory
  DomainJoinConfig:
    DnsName: $DNS_DOMAIN_NAME
    DnsTreeName: $DNS_ROOT_DOMAIN_NAME
    Guid:  $AD_DOMAIN_OBJECT_GUID
    MachineAccountName: $GMSA_ACCOUNT_USERNAME
    NetBiosName: $NETBIOS_DOMAIN_NAME
    Sid: $GMSA_SID

Hinweis

AKS hat in der Version v20230903 die apiVersion von GMSACredentialSpec von windows.k8s.io/v1alpha1 auf windows.k8s.io/v1 aktualisiert.

Erstellen Sie eine neue YAML-Datei mit dem Namen gmsa-role.yaml, und fügen Sie den folgenden YAML-Code ein.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aks-gmsa-role
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["aks-gmsa-spec"]

Erstellen Sie eine neue YAML-Datei mit dem Namen gmsa-role-binding.yaml, und fügen Sie den folgenden YAML-Code ein.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-aks-gmsa-spec
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: aks-gmsa-role
  apiGroup: rbac.authorization.k8s.io

Wenden Sie die Änderungen aus gmsa-spec.yaml, gmsa-role.yaml und gmsa-role-binding.yaml an, indem Sie den Befehl kubectl apply ausführen.
```
kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml
```

Überprüfen der GMSA-Installation

Erstellen Sie eine neue YAML-Datei mit dem Namen gmsa-demo.yaml, und fügen Sie den folgenden YAML-Code ein.

---
kind: ConfigMap
apiVersion: v1
metadata:
  labels:
   app: gmsa-demo
  name: gmsa-demo
  namespace: default
data:
  run.ps1: |
   $ErrorActionPreference = "Stop"

   Write-Output "Configuring IIS with authentication."

   # Add required Windows features, since they are not installed by default.
   Install-WindowsFeature "Web-Windows-Auth", "Web-Asp-Net45"

   # Create simple ASP.NET page.
   New-Item -Force -ItemType Directory -Path 'C:\inetpub\wwwroot\app'
   Set-Content -Path 'C:\inetpub\wwwroot\app\default.aspx' -Value 'Authenticated as <B><%=User.Identity.Name%></B>, Type of Authentication: <B><%=User.Identity.AuthenticationType%></B>'

   # Configure IIS with authentication.
   Import-Module IISAdministration
   Start-IISCommitDelay
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/windowsAuthentication').Attributes['enabled'].value = $true
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/anonymousAuthentication').Attributes['enabled'].value = $false
   (Get-IISServerManager).Sites[0].Applications[0].VirtualDirectories[0].PhysicalPath = 'C:\inetpub\wwwroot\app'
   Stop-IISCommitDelay

   Write-Output "IIS with authentication is ready."

   C:\ServiceMonitor.exe w3svc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gmsa-demo
  template:
    metadata:
      labels:
        app: gmsa-demo
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: aks-gmsa-spec
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: IfNotPresent
        command:
         - powershell
        args:
          - -File
          - /gmsa-demo/run.ps1
        volumeMounts:
          - name: gmsa-demo
            mountPath: /gmsa-demo
      volumes:
      - configMap:
          defaultMode: 420
          name: gmsa-demo
        name: gmsa-demo
      nodeSelector:
        kubernetes.io/os: windows
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: gmsa-demo
  type: LoadBalancer

Wenden Sie die Änderungen aus gmsa-demo.yaml mithilfe des Befehls kubectl apply an.
```
kubectl apply -f gmsa-demo.yaml
```

Rufen Sie die IP-Adresse der Beispielanwendung mit dem Befehl kubectl get service ab.

kubectl get service gmsa-demo --watch

Die EXTERNAL-IP für den Dienst gmsa-demo wird zunächst als ausstehend angezeigt:

NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
gmsa-demo          LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s

Nachdem die EXTERNAL-IP-Adresse von pending (ausstehend) in eine tatsächliche öffentliche IP-Adresse geändert wurde, verwenden Sie CTRL-C, um die kubectl-Überwachung zu beenden.

Die folgende Beispielausgabe zeigt eine gültige öffentliche IP-Adresse, die dem Dienst zugewiesen ist:
```
gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
```
Öffnen Sie in einem Webbrowser die externe IP-Adresse des gmsa-demo-Diensts.
Authentifizieren Sie sich mit $NETBIOS_DOMAIN_NAME\$AD_USERNAME und dem entsprechenden Kennwort, und überprüfen Sie, ob Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate angezeigt wird.

Deaktivieren von GMSA für einen vorhandenen Cluster

Deaktivieren Sie GMSA in einem vorhandenen Cluster mit Windows Server-Knoten mithilfe des Befehls „az aks update“.
```
az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-windows-gmsa 
```

Hinweis

Sie können GMSA in einem vorhandenen Cluster mithilfe des Befehls az aks update erneut aktivieren.

Problembehandlung

Wenn die Seite geladen wird, Sie aber nicht zur Authentifizierung aufgefordert werden, verwenden Sie den Befehl kubectl logs POD_NAME, um die Protokolle Ihres Pods anzuzeigen und sicherzustellen, dass IIS mit Authentifizierung bereitsteht.

Hinweis

Windows-Container zeigen in kubectl standardmäßig keine Protokolle an. Damit Windows-Container Protokolle zeigen können, müssen Sie das Tool Log Monitor in Ihr Windows-Image einbetten. Weitere Informationen erhalten Sie unter Windows-Containertools.

Verbindungszeitüberschreitung beim Versuch, die Seite zu laden

Wenn bei dem Versuch, die Seite zu laden, ein Verbindungstimeout auftritt, überprüfen Sie mit dem Befehl kubectl get pods --watch, ob die Beispiel-App ausgeführt wird. Manchmal ist die externe IP-Adresse für den App-Beispieldienst verfügbar, bevor der App-Beispielpod ausgeführt wird.

Fehler beim Starten des Pods und winapi-Fehler in den Podereignissen

Wenn Ihr Pod nach dem Ausführen des Befehls kubectl get pods --watch und mehreren Minuten Wartezeit nicht gestartet wird, verwenden Sie den Befehl kubectl describe pod POD_NAME. Wenn ein winapi-Fehler in den Podereignissen angezeigt wird, liegt möglicherweise ein Fehler bei der Konfiguration der Spezifikation Ihrer GMSA-Anmeldeinformationen vor. Überprüfen Sie, ob alle Ersetzungswerte in gmsa-spec.yaml richtig sind, führen Sie kubectl apply -f gmsa-spec.yaml erneut aus, und stellen Sie die Beispielanwendung erneut bereit.

Nächste Schritte

Weitere Informationen finden Sie unter Überlegungen zu Windows-Containern mit Azure Kubernetes Service (AKS).

Freigeben über

Aktivieren von gruppenverwalteten Dienstkonten (GMSAs) für Ihre Windows Server-Knoten auf Ihrem AKS-Cluster (Azure Kubernetes Service)

Voraussetzungen

Konfigurieren eines gruppenverwalteten Dienstkontos auf einem Active Directory-Domänencontroller

Speichern der Standardbenutzeranmeldeinformationen für die Domäne in Azure Key Vault

Optional: Verwenden eines benutzerdefinierten VNet mit benutzerdefiniertem DNS

Optional: Konfigurieren mehrerer DNS-Server

Optional: Verwenden Ihrer eigenen Kubelet-Identität für Ihren Cluster

Aktivieren von GMSA auf einem neuen AKS-Cluster

Aktivieren von GMSA für einen vorhandenen Cluster

Gewähren des Zugriffs auf Ihren Schlüsseltresor für die Kubelet-Identität

Installieren der GMSA-CRED-Spezifikation

Überprüfen der GMSA-Installation

Deaktivieren von GMSA für einen vorhandenen Cluster

Problembehandlung

Beim Laden der Seite wird keine Authentifizierung angezeigt

Verbindungszeitüberschreitung beim Versuch, die Seite zu laden

Fehler beim Starten des Pods und winapi-Fehler in den Podereignissen

Nächste Schritte

Zusätzliche Ressourcen