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

  • Articolo

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 account del servizio gestito (gMSA) 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 al dominio, ma molte applicazioni Windows eseguite nei contenitori Windows richiedono ancora l'autenticazione di ACTIVE Directory.

Nota

Per informazioni su come la community kubernetes supporta l'uso di gMSA con contenitori Windows, vedere Configurare gMSA.

Architettura di gMSA 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 gMSA. 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 per la configurazione di gMSA per i contenitori con un host non aggiunto a un dominio:

Diagramma degli account del servizio gestito del gruppo versione due

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

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

Quando gMSA è stato inizialmente introdotto, è necessario che l'host del contenitore sia aggiunto a un dominio, che ha creato un sacco di sovraccarico per aggiungere manualmente i nodi di lavoro di 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 aggiunti al dominio. Altri miglioramenti per gMSA includono quanto segue:

  • Eliminando il requisito di aggiungere manualmente i nodi di lavoro di Windows a un dominio, che ha causato un sovraccarico elevato. Per gli scenari di scalabilità, 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 gMSA.
  • Un processo end-to-end meno complicato per configurare gMSA con Kubernetes.

Prima di iniziare

Per eseguire un contenitore Windows con un account del servizio gestito del gruppo, è necessario quanto segue:

  • Un dominio di Active Directory con almeno un controller di dominio che esegue Windows Server 2012 o versione successiva. Non esistono requisiti di livello funzionale della foresta o del dominio per l'uso di gMSA, ma le password gMSA possono essere distribuite solo dai controller di dominio che eseguono Windows Server 2012 o versioni successive. 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 gMSA, è necessario essere un amministratore di dominio o usare un account che ha concesso l'autorizzazione per creare oggetti msDS-GroupManagedServiceAccount.
  • Accedere 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 sincronizzare il tempo con un controller di dominio o con un'altra origine temporale. È anche necessario assicurarsi che Hyper-V sia configurato per sincronizzare il tempo in qualsiasi macchina virtuale.

Preparare gMSA nel controller di dominio

Seguire questa procedura per preparare gMSA nel controller di dominio:

  1. Nel controller di dominio preparare Active Directory e creare l'account gMSA.

  2. Creare un account utente di dominio. Questo account utente/password verrà salvato come segreto Kubernetes e usato per recuperare la password gMSA.

  3. Per creare un account GMSA e concedere l'autorizzazione per leggere la password per l'account gMSA creato nel passaggio 2, eseguire il comando New-ADServiceAccount PowerShell 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 del 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 delle credenziali gMSA

Per preparare il file JSON delle credenziali gMSA, seguire la procedura per creare una specifica delle credenziali.

Configurare gMSA per pod e contenitori Windows nel cluster

La community kubernetes supporta già i nodi di lavoro windows aggiunti al dominio per gMSA. Anche se non è necessario aggiungere un dominio a un nodo di lavoro Windows nel servizio Azure Kubernetes in Azure Stack HCI e Windows Server, sono disponibili altri passaggi di configurazione necessari. Questi passaggi includono l'installazione del webhook, la definizione di risorsa personalizzata (CRD) e le specifiche delle credenziali, nonché l'abilitazione del controllo degli accessi in base al ruolo (ruolo 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.

  1. Per installare il webhook, eseguire il comando Install-AksHciGmsaWebhook powerShell 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.

  2. Creare 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 dal valore predefinito, ricordare di impostare lo spazio dei nomi della distribuzione sullo stesso spazio dei nomi.

  3. Usare il cmdlet Add-AksHciGMSACredentialSpec powerShell per creare il crD gMSA, abilitare il controllo degli accessi in base al ruolo e quindi assegnare il ruolo agli account del servizio per usare un file specifico di specifiche specifiche credenziali gMSA. Questi passaggi sono descritti in dettaglio in questo articolo di Kubernetes su Configura gMSA per i pod e i contenitori di Windows.

    Usare la specifica delle credenziali JSON come input per il comando di PowerShell seguente (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

Creare il file YAML di distribuzione usando le impostazioni di esempio seguenti. Le voci necessarie includono serviceAccountName, , volumeMountsgmsaCredentialSpecNamee dnsconfig.

  1. Aggiungere l'account del servizio:

    serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

  2. Aggiungere l'oggetto spec delle credenziali:

    securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

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

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

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

Verificare che il contenitore funzioni con gMSA

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

  1. Ottenere l'ID contenitore per la distribuzione eseguendo il comando seguente:

    kubectl get pods

  2. Aprire PowerShell ed eseguire il comando seguente:

    kubectl exec -it <container id> powershell

  3. Dopo aver eseguito il contenitore, eseguire quanto segue:

    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 esiste un canale sicuro tra il computer client e il controller di dominio.

  4. Verificare se il contenitore può ottenere un ticket di concessione di ticket Kerberos valido (TGT).

    klist get krbtgt

    A ticket to krbtgt has been retrieved successfully

Pulire le impostazioni gMSA nel cluster

Se è necessario pulire le impostazioni gMSA, seguire questa procedura di disinstallazione.

Disinstallare la specifica delle credenziali

Per disinstallare, eseguire il comando Remove-AksHcigmsaCredentialSpec PowerShell 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 webhook

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

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Passaggi successivi