Configurare gli account del servizio gestito del gruppo per i contenitori Windows con servizio Azure Kubernetes in Azure Stack HCI e Windows Server

Articolo
05/01/2024

Si applica a: servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

Per usare l'autenticazione di Active Directory, è possibile configurare gli account del servizio gestito del gruppo per i contenitori Windows da eseguire con un host non aggiunto a un dominio. Un account del servizio gestito di gruppo è un tipo speciale di account del servizio introdotto in Windows Server 2012 progettato per consentire a più computer di condividere un'identità senza conoscere la password. I contenitori di Windows non possono essere aggiunti a un dominio, ma molte applicazioni Windows eseguite nei contenitori di Windows richiedono ancora l'autenticazione di Active Directory.

Nota

Per informazioni su come la community di Kubernetes supporta l'uso di gMSA con contenitori Windows, vedere Configurare l'account del servizio gestito del gruppo.

Architettura dell'account del servizio gestito del gruppo per i contenitori con un host non aggiunto a un dominio

gMSA per i contenitori con un host non aggiunto a un dominio usa un'identità utente portabile anziché un'identità host per recuperare le credenziali del servizio gestito del gruppo. Pertanto, l'aggiunta manuale dei nodi di lavoro di Windows a un dominio non è più necessaria. L'identità utente viene salvata come segreto in Kubernetes. Il diagramma seguente illustra il processo di configurazione dell'account del servizio gestito del gruppo per i contenitori con un host non aggiunto a un dominio:

Diagramma degli account del servizio gestito del gruppo versione 2

GMSA per i contenitori con un host non aggiunto a un dominio offre la flessibilità necessaria per la creazione di contenitori con account del servizio gestito del gruppo senza aggiungere il nodo host al dominio. A partire da Windows Server 2019, ccg.exe è supportato, che consente a un meccanismo di plug-in di recuperare le credenziali del servizio gestito del gruppo da Active Directory. È possibile usare tale identità per avviare il contenitore. Per altre informazioni su ccg.exe, vedere Interfaccia ICcgDomainAuthCredentials.

Confronto tra gMSA per contenitori con un host non aggiunto a un dominio e un host aggiunto a un dominio

Quando gMSA è stato introdotto inizialmente, è necessario che l'host contenitore sia aggiunto a un dominio, che ha creato un notevole sovraccarico per aggiungere manualmente i nodi di lavoro Windows a un dominio. Questa limitazione è stata risolta con gMSA per i contenitori con un host non aggiunto a un dominio, quindi gli utenti possono ora usare gMSA con host non collegati al dominio. Altri miglioramenti al servizio gestito del gruppo includono le funzionalità seguenti:

Eliminando il requisito di aggiungere manualmente nodi di lavoro Windows a un dominio, causando un sovraccarico elevato. Per gli scenari di ridimensionamento, questo semplifica il processo.
Negli scenari di aggiornamento in sequenza, gli utenti non devono più ricongiuntire il nodo a un dominio.
Un processo più semplice per la gestione degli account del computer del nodo di lavoro per recuperare le password dell'account del servizio del servizio gestito del gruppo.
Un processo end-to-end meno complesso per configurare l'account del servizio gestito del gruppo con Kubernetes.

Prima di iniziare

Per eseguire un contenitore di Windows con un account del servizio gestito del gruppo, sono necessari i prerequisiti seguenti:

Un dominio di Active Directory con almeno un controller di dominio che esegue Windows Server 2012 o versione successiva. Non esistono requisiti a livello di funzionalità della foresta o del dominio per l'uso di account del servizio gestito del gruppo, ma solo i controller di dominio che eseguono Windows Server 2012 o versioni successive possono distribuire le password del servizio gestito del gruppo. Per altre informazioni, vedi Requisiti di Active Directory per gli account del servizio gestito di gruppo.
Autorizzazione per la creazione di un account del servizio gestito di gruppo. Per creare un account del servizio gestito del gruppo, è necessario essere un amministratore di dominio o usare un account con autorizzazioni per creare oggetti msDS-GroupManagedServiceAccount .
Accesso a Internet per scaricare il modulo PowerShell CredentialSpec . Se stai lavorando in un ambiente disconnesso, puoi salvare il modulo in un computer con accesso a Internet e copiarlo nel computer di sviluppo o nell'host del contenitore.
Per garantire il funzionamento dell'autenticazione gMSA e AD, assicurarsi che i nodi del cluster Azure Stack HCI e Windows Server siano configurati per sincronizzarne l'ora con un controller di dominio o un'altra origine temporale. È anche necessario assicurarsi che Hyper-V sia configurato per sincronizzare l'ora con qualsiasi macchina virtuale.

Preparare l'account del servizio gestito del gruppo nel controller di dominio

Seguire questa procedura per preparare l'account del servizio gestito del gruppo nel controller di dominio:

Nel controller di dominio preparare Active Directory e creare l'account del servizio gestito del gruppo.
Create un account utente di dominio. Queste credenziali dell'account utente/password vengono salvate come segreto Kubernetes e usate per recuperare la password del servizio gestito del gruppo.

Per creare un account GMSA e concedere l'autorizzazione per leggere la password per l'account del servizio gestito del gruppo creato nel passaggio 2, eseguire il comando PowerShell New-ADServiceAccount seguente:

 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>

Per -PrincipalsAllowedToRetrieveManagedPassword, specificare il nome utente di dominio creato in precedenza, come illustrato nell'esempio seguente:

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

Preparare il file JSON della specifica delle credenziali del servizio gestito del gruppo

Per preparare il file JSON delle specifiche delle credenziali del servizio gestito del gruppo, seguire la procedura per la creazione di una specifica di credenziali.

Configurare gMSA per pod e contenitori Windows nel cluster

La community di Kubernetes supporta già nodi di lavoro Windows aggiunti a un dominio per l'account del servizio gestito del gruppo. Anche se non è necessario aggiungere un dominio a un nodo di lavoro Windows nel servizio Azure Kubernetes in Azure Stack HCI e Windows Server, esistono altri passaggi di configurazione necessari. Questi passaggi includono l'installazione del webhook, la definizione di risorsa personalizzata e la specifica delle credenziali e l'abilitazione del controllo degli accessi in base al ruolo. I passaggi seguenti usano i comandi di PowerShell compilati per semplificare il processo di configurazione.

Prima di completare i passaggi seguenti, assicurarsi che il modulo AksHci PowerShell sia installato e kubectl possa connettersi al cluster.

Per installare il webhook, eseguire il comando PowerShell Install-AksHciGmsaWebhook seguente:
```
Install-AksHciGMSAWebhook -Name <cluster name>
```
Per verificare che il pod webhook sia in esecuzione correttamente, eseguire il comando seguente:
```
kubectl get pods -n kube-system | findstr gmsa
```
Verrà visualizzato un pod con il prefisso gmsa-webhook in esecuzione.
Create l'oggetto segreto che archivia le credenziali utente di Active Directory. Completare i dati di configurazione seguenti e salvare le impostazioni in un file denominato 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>
```
Eseguire quindi il comando seguente per creare l'oggetto segreto:
```
kubectl apply -f secret.yaml
```
Nota

Se si crea un segreto in uno spazio dei nomi diverso da quello predefinito, ricordarsi di impostare lo spazio dei nomi della distribuzione sullo stesso spazio dei nomi.
Usare il cmdlet di PowerShell Add-AksHciGMSACredentialSpec per creare il CRD del servizio gestito del gruppo, abilitare il controllo degli accessi in base al ruolo e quindi assegnare il ruolo agli account del servizio per usare un file specifico delle specifiche delle credenziali del servizio gestito del gruppo. Questi passaggi sono descritti in modo più dettagliato in questo articolo di Kubernetes su Configurare gMSA per pod e contenitori Windows.

Usare la specifica di credenziale JSON come input per il comando di PowerShell seguente (i parametri con asterischi * sono obbligatori):
```
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 
```
Per visualizzare un esempio, vedere il codice seguente:
```
Add-AksHciGMSACredentialSpec -Name mynewcluster 
  -credSpecFilePath .\credspectest.json 
  -credSpecName credspec-mynewcluster 
  -secretName mysecret 
  -clusterRoleName clusterrole-mynewcluster
```

Distribuire l'applicazione

Create il file YAML di distribuzione usando le impostazioni di esempio seguenti. Le voci necessarie includono serviceAccountName, gmsaCredentialSpecName, volumeMountse dnsconfig.

Aggiungere l'account del servizio:

serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

Aggiungere l'oggetto specifica delle credenziali:

securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

Montare il segreto per la distribuzione:

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

Aggiungere l'indirizzo IP del controller di dominio e del nome di dominio in dnsConfig:

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

Verificare che il contenitore funzioni con l'account del servizio gestito del gruppo

Dopo aver distribuito il contenitore, seguire questa procedura per verificare che funzioni:

Ottenere l'ID contenitore per la distribuzione eseguendo il comando seguente:
```
kubectl get pods
```
Aprire PowerShell ed eseguire il comando seguente:
```
kubectl exec -it <container id> powershell
```
Quando si è nel contenitore, eseguire il comando seguente:
```
Nltest /parentdomain 
Nltest /sc_verify:<domain> 
```
```
Connection Status = 0 0x0 NERR_Success The command completed successfully. 
```
Questo output mostra che il computer è stato autenticato da un controller di dominio e che esiste un canale sicuro tra il computer client e il controller di dominio.
Controllare se il contenitore può ottenere un ticket di concessione ticket (TGT) Kerberos valido.
```
klist get krbtgt
```
```
A ticket to krbtgt has been retrieved successfully
```

Pulire le impostazioni del servizio gestito del gruppo nel cluster

Se è necessario pulire le impostazioni del servizio gestito del gruppo, seguire questa procedura di disinstallazione.

Disinstallare la specifica di credenziali

Per disinstallare, eseguire il comando di PowerShell Remove-AksHcigmsaCredentialSpec seguente:

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

Disinstallare il webhook

Per disinstallare il webhook, eseguire il comando di PowerShell Uninstall-AksHciGMSAWebhook seguente:

Uninstall-AksHciGMSAWebhook -Name <cluster name>