Abilitare gli account del servizio gestito del gruppo (GMSA) per i nodi Windows Server nel cluster del servizio Azure Kubernetes

Gli account del servizio gestito del gruppo (GMSA) sono un account di dominio gestito per più server che fornisce la gestione automatica delle password, la gestione semplificata del nome dell'entità servizio (SPN) e la possibilità di delegare la gestione ad altri amministratori. Con il servizio Azure Kubernetes è possibile abilitare GMSA nei nodi di Windows Server, che consente ai contenitori in esecuzione nei nodi di Windows Server di integrarsi con e essere gestiti da GMSA.

Prerequisiti

• Kubernetes 1.19 o versione successiva. Per verificare la versione, vedere Verificare la disponibilità di aggiornamenti. Per aggiornare la versione, vedere Aggiornare il cluster del servizio Azure Kubernetes.
• Interfaccia della riga di comando di Azure 2.35.0 o versione successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
• Identità gestite abilitate nel cluster del servizio Azure Kubernetes.
• Autorizzazioni per creare o aggiornare un insieme di credenziali delle chiavi di Azure.
• Autorizzazioni per configurare GMSA nel servizio di dominio Active Directory o in Active Directory locale.
• Il controller di dominio deve avere Servizi Web Active Directory abilitati e deve essere raggiungibile sulla porta 9389 dal cluster del servizio Azure Kubernetes.

Configurare GMSA nel controller di dominio di Active Directory

Per usare GMSA con il servizio Azure Kubernetes, è necessaria una credenziale utente di dominio standard per accedere alle credenziali GMSA configurate nel controller di dominio. Per configurare GMSA nel controller di dominio, vedere Introduzione agli account del servizio gestito del gruppo. Per le credenziali utente di dominio standard, è possibile usare un utente esistente o crearne uno nuovo, purché abbia accesso alle credenziali GMSA.

Archiviare le credenziali utente di dominio standard in Azure Key Vault

Il cluster del servizio Azure Kubernetes usa le credenziali utente di dominio standard per accedere alle credenziali GMSA dal controller di dominio. Per fornire l'accesso sicuro a tali credenziali per il cluster del servizio Azure Kubernetes, è necessario archiviarli in Azure Key Vault.

1. Se non si ha già un insieme di credenziali delle chiavi di Azure, crearne uno usando il comando az keyvault create.

   az keyvault create --resource-group myResourceGroup --name myGMSAVault
   

2. Archiviare le credenziali utente di dominio standard come segreto nell'insieme di credenziali delle chiavi usando il comando az keyvault secret set. L'esempio seguente archivia le credenziali utente di dominio con la chiave GMSADomainUserCred nell'insieme di credenziali delle chiavi myGMSAVault.

   az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
   

   Nota

   Assicurarsi di usare il nome di dominio completo per il dominio.

Facoltativo: usare una rete virtuale personalizzata con DNS personalizzato

È necessario configurare il controller di dominio tramite DNS in modo che sia raggiungibile dal cluster del servizio Azure Kubernetes. È possibile configurare la rete e il DNS all'esterno del cluster del servizio Azure Kubernetes per consentire al cluster di accedere al controller di dominio. In alternativa, è possibile usare Azure CNI per configurare una rete virtuale personalizzata con un DNS personalizzato nel cluster del servizio Azure Kubernetes per fornire l'accesso al controller di dominio. Per altre informazioni, vedere Configurare la rete CNI di Azure nel servizio Azure Kubernetes.

Facoltativo: configurare più server DNS

Se si vuole configurare più server DNS per Windows GMSA nel cluster del servizio Azure Kubernetes, non specificare --gmsa-dns-server o v--gmsa-root-domain-name. È invece possibile aggiungere più server DNS nella rete virtuale selezionando DNS personalizzato e aggiungendo i server DNS.

Facoltativo: usare la propria identità kubelet per il cluster

Per fornire al cluster del servizio Azure Kubernetes l'accesso all'insieme di credenziali delle chiavi, l'identità kubelet del cluster deve accedere all'insieme di credenziali delle chiavi. Quando si crea un cluster con identità gestita abilitata, per impostazione predefinita viene creata automaticamente un'identità kubelet.

È possibile concedere l'accesso all'insieme di credenziali delle chiavi per l'identità dopo la creazione del cluster o creare la propria identità da usare prima della creazione del cluster seguendo questa procedura:

1. Creare un'identità kubelet usando il comando az identity create.

   az identity create --name myIdentity --resource-group myResourceGroup
   

2. Ottenere l'ID dell'identità usando il comando az identity list e impostarlo su una variabile denominata MANAGED_ID.

   MANAGED_ID=$(az identity list --query "[].id" -o tsv)
   

3. Concedere all'identità l'accesso all'insieme di credenziali delle chiavi usando il comando az keyvault set-policy.

   az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
   

Abilitare GMSA in un nuovo cluster del servizio Azure Kubernetes

1. Creare le credenziali di amministratore da usare durante la creazione del cluster. I comandi seguenti richiedono un nome utente e lo impostano su WINDOWS_USERNAME da usare in un comando successivo.

   echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
   

2. Creare un cluster del servizio Azure Kubernetes usando il comando az aks create con i parametri seguenti:

   • --enable-windows-gmsa: abilita GMSA per il cluster.
   • --gmsa-dns-server: indirizzo IP del server DNS.
   • --gmsa-root-domain-name: nome di dominio radice del server DNS.

   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
   

   Nota

   • Se si usa una rete virtuale personalizzata, è necessario specificare l'ID rete virtuale usando il parametro vnet-subnet-id e potrebbe essere necessario aggiungere anche i parametri docker-bridge-address, dns-service-ip e service-cidr a seconda della configurazione.

   • Se è stata creata la propria identità per l'identità kubelet, usare il parametro assign-kubelet-identity per specificare l'identità.

   • Quando si specificano i parametri --gmsa-dns-server e --gmsa-root-domain-name, viene aggiunta una regola di inoltro DNS al kube-system/coredns ConfigMap. Questa regola inoltra le richieste DNS per $ROOT_DOMAIN_NAME dai pod al $DNS_SERVER.

     $ROOT_DOMAIN_NAME:53 {
         errors
         cache 30
         log
         forward . $DNS_SERVER
     }
     

3. Aggiungere un pool di nodi di Windows Server usando il comando az aks nodepool add.

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

Abilitare GMSA nel cluster esistente

• Abilitare GMSA in un cluster esistente con nodi di Windows Server e identità gestite abilitate usando il comando 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
  

Concedere l'accesso all'insieme di credenziali delle chiavi per l'identità kubelet

• Concedere l'accesso all'insieme di credenziali delle chiavi per l'identità kubelet usando il comando 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
  

Installare la specifica di cred GMSA

1. Configurare kubectl per connettersi al cluster Kubernetes usando il comando az aks get-credentials.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
   

2. Creare un nuovo YAML denominato gmsa-spec.yaml e incollare il codice YAML seguente. Assicurarsi di sostituire i segnaposto con i propri valori.

   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
   

3. Creare un nuovo YAML denominato gmsa-role.yaml e incollare il codice YAML seguente.

   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"]
   

4. Creare un nuovo YAML denominato gmsa-role-binding.yaml e incollare il codice YAML seguente.

   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
   

5. Applicare le modifiche da gmsa-spec.yaml, gmsa-role.yaml e gmsa-role-binding.yaml usando il comando kubectl apply.

   kubectl apply -f gmsa-spec.yaml
   kubectl apply -f gmsa-role.yaml
   kubectl apply -f gmsa-role-binding.yaml
   

Verificare l'installazione di GMSA

1. Creare un nuovo YAML denominato gmsa-demo.yaml e incollare il codice YAML seguente.

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

2. Applicare le modifiche da gmsa-demo.yaml usando il comando kubectl apply.

   kubectl apply -f gmsa-demo.yaml
   

3. Ottenere l'indirizzo IP dell'applicazione di esempio usando il comando kubectl get service.

   kubectl get service gmsa-demo --watch
   

   Inizialmente, EXTERNAL-IP per il servizio gmsa-demo viene visualizzato come in sospeso:

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

4. Quando l'indirizzo EXTERNAL-IP passa da in sospeso a un indirizzo IP pubblico effettivo, usare CTRL-C per arrestare il processo di controllo kubectl.

   L'output di esempio seguente mostra un indirizzo IP pubblico valido assegnato al servizio:

   gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
   

5. Aprire un Web browser per l'indirizzo IP esterno del servizio gmsa-demo.

6. Eseguire l'autenticazione con $NETBIOS_DOMAIN_NAME\$AD_USERNAME e la password e verificare che venga visualizzato Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate.

Disabilitare GMSA in un cluster esistente

• Disabilitare GMSA in un cluster esistente con nodi di Windows Server usando il comando az aks update.

  az aks update \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --disable-windows-gmsa 
  

Risoluzione dei problemi

Non viene richiesta alcuna autenticazione durante il caricamento della pagina

Se la pagina viene caricata, ma non viene richiesto di eseguire l'autenticazione, usare il comando kubectl logs POD_NAME per visualizzare i log del pod e verificare che IIS con autenticazione sia pronto.

Timeout della connessione quando si tenta di caricare la pagina

Se si riceve un timeout di connessione quando si tenta di caricare la pagina, verificare che l'app di esempio sia in esecuzione usando il comando kubectl get pods --watch. A volte l'indirizzo IP esterno per il servizio app di esempio è disponibile prima che il pod dell'app di esempio sia in esecuzione.

L'avvio del pod non riesce e viene visualizzato un errore winapi negli eventi del pod

Se il pod non viene avviato dopo aver eseguito il comando kubectl get pods --watch e aver atteso alcuni minuti, usare il comando kubectl describe pod POD_NAME. Se viene visualizzato un errore winapi negli eventi del pod, è probabile che si verifichi un errore nella configurazione della specifica di cred GMSA. Verificare che tutti i valori di sostituzione in gmsa-spec.yaml siano corretti, eseguire di nuovo kubectl apply -f gmsa-spec.yaml e ridistribuire l'applicazione di esempio.

Passaggi successivi

Per altre informazioni, vedere Considerazioni sui contenitori di Windows con servizio Azure Kubernetes (servizio Azure Kubernetes).