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

Articolo
05/07/2024

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.

Nota

Microsoft offre anche un modulo powerShell appositamente compilato per configurare l'account del servizio gestito del gruppo nel servizio Azure Kubernetes. Per altre informazioni, vedere gMSA nel 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.

Importante

È necessario usare Active Directory Domain Service o Active Directory locale. Al momento non è possibile usare Microsoft Entra ID per configurare GMSA con un cluster del servizio Azure Kubernetes.

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.

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

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

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

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

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

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

Nota

Ignorare questo passaggio se è stata specificata la propria identità 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

Configurare kubectl per connettersi al cluster Kubernetes usando il comando az aks get-credentials.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

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

Nota

Il servizio Azure Kubernetes ha aggiornato apiVersion di GMSACredentialSpec da windows.k8s.io/v1alpha1 a windows.k8s.io/v1 nella versione 20230903.

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

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

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

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

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

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

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
```
Aprire un Web browser per l'indirizzo IP esterno del servizio gmsa-demo.
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

Nota

È possibile riabilitare GMSA in un cluster esistente usando il comando az aks update.

Risoluzione dei problemi

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.

Nota

I contenitori di Windows non visualizzano i log in kubectl per impostazione predefinita. Per consentire ai contenitori di Windows di visualizzare i log, è necessario incorporare lo strumento Monitoraggio log nell'immagine di Windows. Per altre informazioni, vedere Strumenti contenitore di Windows.

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

Altre informazioni sui contenitori di Windows Server nel servizio Azure Kubernetes.

Condividi tramite

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

Prerequisiti

Configurare GMSA nel controller di dominio di Active Directory

Archiviare le credenziali utente di dominio standard in Azure Key Vault

Facoltativo: usare una rete virtuale personalizzata con DNS personalizzato

Facoltativo: configurare più server DNS

Facoltativo: usare la propria identità kubelet per il cluster

Abilitare GMSA in un nuovo cluster del servizio Azure Kubernetes

Abilitare GMSA nel cluster esistente

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

Installare la specifica di cred GMSA

Verificare l'installazione di GMSA

Disabilitare GMSA in un cluster esistente

Risoluzione dei problemi

Non viene richiesta alcuna autenticazione durante il caricamento della pagina

Timeout della connessione quando si tenta di caricare la pagina

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

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive