Configurer des comptes de service administré de groupe (gMSA) pour les conteneurs Windows avec Azure Kubernetes Service sur Azure Local et Windows Server

Article
05/01/2024

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

Pour utiliser l’authentification AD, vous pouvez configurer des comptes de service administrés de groupe (gMSA) pour des conteneurs Windows afin qu’ils s’exécutent avec un hôte qui n’est pas joint à un domaine. Un compte de service administré de groupe est un type spécial de compte de service introduit dans Windows Server 2012, conçu pour permettre à plusieurs ordinateurs de partager une identité sans connaître le mot de passe. Les conteneurs Windows ne peuvent pas être joints à un domaine, mais de nombreuses applications Windows qui s’exécutent dans des conteneurs Windows ont encore besoin d’une authentification AD.

Remarque

Pour savoir comment la communauté Kubernetes prend en charge l’utilisation de gMSA avec des conteneurs Windows, consultez ce document sur la configuration de gMSA.

Architecture de gMSA pour conteneurs avec un hôte qui n’est pas joint à un domaine

Un gMSA pour conteneurs avec un hôte qui n’est pas joint à un domaine utilise une identité d’utilisateur portable au lieu d’une identité d’hôte pour récupérer les informations d’identification gMSA. Ainsi, la jonction manuelle des nœuds Worker Windows à un domaine n’est plus nécessaire. L’identité de l’utilisateur est enregistrée en tant que secret dans Kubernetes. Le diagramme suivant montre le processus de configuration de gMSA pour les conteneurs avec un hôte non joint à un domaine :

Diagramme de comptes de service administrés de groupe version 2

Un gMSA pour conteneurs avec un hôte qui n’est pas joint à un domaine offre la flexibilité de créer des conteneurs avec gMSA sans joindre le nœud hôte au domaine. À compter de Windows Server 2019, ccg.exe est pris en charge, ce qui permet à un mécanisme de plug-in de récupérer les informations d’identification gMSA à partir d’Active Directory. Vous pouvez utiliser cette identité pour démarrer le conteneur. Pour plus d’informations sur ccg.exe, consultez ce document sur l’interface ICcgDomainAuthCredentials.

Comparaison entre gMSA pour conteneurs avec un hôte qui n’est pas joint à un domaine et un hôte joint à un domaine

Lors de l’introduction initiale des gMSA, l’hôte de conteneur devait être joint à un domaine, ce qui générait une surcharge importante pour les utilisateurs, car ils devaient joindre manuellement les nœuds Worker Windows à un domaine. Cette limitation a été traitée avec gMSA pour les conteneurs avec un hôte non joint à un domaine, afin que les utilisateurs puissent désormais utiliser gMSA avec des hôtes non joints à un domaine. Les autres améliorations apportées à gMSA incluent les fonctionnalités suivantes :

Plus besoin de joindre manuellement des nœuds Worker Windows à un domaine, qui entraînait une surcharge de travail importante. Pour les scénarios de mise à l’échelle, cela simplifie le processus.
Dans les scénarios de mise à jour propagée, les utilisateurs ne doivent plus joindre le nœud à un domaine.
Simplification du processus de gestion des comptes d’ordinateur de nœud Worker afin de récupérer les mots de passe du compte de service gMSA.
Processus de bout en bout moins complexe pour configurer les gMSA avec Kubernetes.

Avant de commencer

Pour exécuter un conteneur Windows avec un compte de service géré de groupe, vous avez besoin des prérequis suivants :

Un domaine Active Directory avec au moins un contrôleur de domaine exécutant Windows Server 2012 ou version ultérieure. Il n’existe aucune exigence de niveau fonctionnel de forêt ou de domaine pour utiliser des gMSA, mais seuls les contrôleurs de domaine exécutant Windows Server 2012 ou version ultérieure peuvent distribuer des mots de passe gMSA. Pour plus d’informations, consultez Exigences Active Directory pour les comptes de service administré de groupe.
L’autorisation de créer un compte de service administré de groupe. Pour créer un compte gMSA, vous devez être administrateur de domaine ou utiliser un compte disposant d’autorisations pour créer des objets msDS-GroupManagedServiceAccount .
Un accès à Internet pour télécharger le module PowerShell CredentialSpec. Si vous travaillez dans un environnement déconnecté, vous pouvez enregistrer le module sur un ordinateur disposant d’un accès à Internet et le copier sur votre ordinateur de développement ou hôte de conteneur.
Pour garantir le travail d’authentification gMSA et AD, vérifiez que les nœuds de cluster Azure Local et Windows Server sont configurés pour synchroniser leur temps avec un contrôleur de domaine ou une autre source de temps. Vous devez également vous assurer que Hyper-V est configuré pour synchroniser l'heure sur toutes les machines virtuelles.

Préparer le gMSA dans le contrôleur de domaine

Procédez comme suit pour préparer le gMSA dans le contrôleur de domaine :

Dans le contrôleur de domaine, préparez Active Directory et créez le compte gMSA.
Créez un compte d’utilisateur de domaine. Ces informations d’identification de compte d’utilisateur/mot de passe sont enregistrées en tant que secret Kubernetes et utilisées pour récupérer le mot de passe gMSA.

Pour créer un compte gMSA et lui accorder l’autorisation de lire le mot de passe du compte gMSA créé à l’étape 2, exécutez la commande PowerShell New-ADServiceAccount suivante :

 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>

Pour -PrincipalsAllowedToRetrieveManagedPassword, spécifiez le nom d’utilisateur de domaine que vous avez créé précédemment, comme indiqué dans l’exemple suivant :

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

Préparer le fichier JSON de spécification des informations d’identification de gMSA

Pour préparer le fichier JSON de spécification d’informations d’identification de gMSA, suivez les étapes de création d’une spécification d’informations d’identification.

Configurer un gMSA pour des conteneurs et pods Windows dans le cluster

La communauté Kubernetes prend déjà en charge les nœuds Worker Windows joints à un domaine pour les gMSA. Bien que vous n’ayez pas besoin de joindre un nœud Worker Windows dans AKS sur Azure Local et Windows Server, il existe d’autres étapes de configuration requises. Ces étapes incluent l’installation du webhook, la définition de ressource personnalisée (CRD) et la spécification des informations d’identification et l’activation du contrôle d’accès en fonction du rôle (rôle RBAC). Les étapes suivantes utilisent des commandes PowerShell qui sont conçues pour simplifier le processus de configuration.

Avant d’effectuer les étapes suivantes, vérifiez que le module PowerShell AksHci est installé et kubectl peut se connecter à votre cluster.

Pour installer le webhook, exécutez la commande PowerShell Install-AksHciGmsaWebhook suivante :
```
Install-AksHciGMSAWebhook -Name <cluster name>
```
Pour vérifier que le pod de webhook est bien en cours d’exécution, exécutez la commande suivante :
```
kubectl get pods -n kube-system | findstr gmsa
```
Vous devez voir un pod avec le préfixe gmsa-webhook en cours d’exécution.
Créez l’objet de secret qui stocke les informations d’identification de l’utilisateur Active Directory. Effectuez les données de configuration suivantes et enregistrez les paramètres dans un fichier nommé 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>
```
Ensuite, exécutez la commande ci-dessous pour créer l’objet de secret :
```
kubectl apply -f secret.yaml
```
Remarque

Si vous créez un secret sous un espace de noms autre que celui par défaut, n’oubliez pas de définir l’espace de noms du déploiement sur le même espace de noms.
Utilisez l’applet de commande PowerShell Add-AksHciGMSACredentialSpec pour créer le CRD gMSA, activer le contrôle d’accès en fonction du rôle (RBAC), puis affecter le rôle aux comptes de service pour utiliser un fichier de spécification d’informations d’identification gMSA spécifique. Ces étapes sont décrites plus en détail dans cet article Kubernetes sur la configuration de gMSA pour les conteneurs et pods Windows.

Utilisez la spécification d’informations d’identification JSON comme entrée de la commande PowerShell suivante (les paramètres avec des astérisques * sont obligatoires) :
```
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 
```
Pour afficher un exemple, consultez le code suivant :
```
Add-AksHciGMSACredentialSpec -Name mynewcluster 
  -credSpecFilePath .\credspectest.json 
  -credSpecName credspec-mynewcluster 
  -secretName mysecret 
  -clusterRoleName clusterrole-mynewcluster
```

Déployer l’application

Créez le fichier de YAML de déploiement à l’aide des paramètres d’exemple suivants. Les entrées requises incluent serviceAccountName, gmsaCredentialSpecName, volumeMounts et dnsconfig.

Ajoutez le compte de service :

serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

Ajoutez l’objet de spécification d’informations d’identification :

securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

Montez le secret pour le déploiement :

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

Ajoutez l’adresse IP du contrôleur de domaine et le nom de domaine sous dnsConfig :

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

Vérifier que le conteneur fonctionne avec le gMSA

Après avoir déployé le conteneur, procédez comme suite pour vérifier qu’il fonctionne :

Exécutez la commande suivante afin d’obtenir l’ID de conteneur de votre déploiement :
```
kubectl get pods
```
Ouvrez PowerShell et exécutez la commande suivante :
```
kubectl exec -it <container id> powershell
```
Une fois que vous êtes dans le conteneur, exécutez la commande suivante :
```
Nltest /parentdomain 
Nltest /sc_verify:<domain> 
```
```
Connection Status = 0 0x0 NERR_Success The command completed successfully. 
```
Cette sortie indique que l’ordinateur a été authentifié par un contrôleur de domaine et qu’un canal sécurisé existe entre l’ordinateur client et le contrôleur de domaine.
Vérifiez si le conteneur peut obtenir un ticket TGT (Ticket Granting Ticket) Kerberos valide.
```
klist get krbtgt
```
```
A ticket to krbtgt has been retrieved successfully
```

Nettoyer les paramètres de gMSA dans le cluster

Si vous devez nettoyer les paramètres de gMSA, effectuez les étapes de désinstallation suivantes.

Désinstaller la spécification d’informations d’identification

Pour désinstaller, exécutez la commande PowerShell Remove-AksHcigmsaCredentialSpec suivante :

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

Désinstaller le webhook

Pour désinstaller le webhook, exécutez la commande PowerShell Uninstall-AksHciGMSAWebhook suivante :

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Partager via