Activer les comptes de services gérés de groupe (gMSA) pour vos nœuds Windows Server sur votre cluster Azure Kubernetes Service (AKS)

Article
08/02/2024

Un compte de service administré du groupe (gMSA) est un compte de domaine managé pour plusieurs serveurs qui fournit la gestion automatique des mots de passe, la gestion simplifiée du nom de principal du service (SPN) et la capacité à déléguer la gestion à d’autres administrateurs. Avec AKS (Azure Kubernetes Service), vous pouvez activer gMSA sur vos nœuds Windows Server, ce qui permet aux conteneurs s’exécutant sur des nœuds Windows Server de s’intégrer au compte gMSA et d’être gérés par lui.

Prérequis

Kubernetes 1.19 ou version ultérieure. Pour vérifier votre version, consultez Rechercher les mises à niveau disponibles. Pour mettre à niveau votre version, consultez Mettre à niveau un cluster AKS.
Azure CLI version 2.35.0 ou ultérieure Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
Identités managées activées sur votre cluster AKS
Autorisations pour créer ou mettre à jour un Azure Key Vault.
Autorisations pour configurer GMSA sur Active Directory Domain Services ou Active Directory local.
Le contrôleur de domaine doit avoir Active Directory Services Web activé et doit être accessible sur le port 9389 par le cluster AKS.

Notes

Microsoft fournit également un module PowerShell spécialement conçu pour configurer gMSA sur AKS. Pour plus d’informations, consultez gMSA sur Azure Kubernetes Service.

Configurer gMSA sur le contrôleur de domaine Active Directory

Pour utiliser gMSA avec AKS, vous avez besoin des informations d’identification d’un utilisateur de domaine standard pour accéder aux informations d’identification gMSA configurées sur votre contrôleur de domaine. Pour configurer gMSA sur votre contrôleur de domaine, consultez Bien démarrer avec les comptes de services administrés du groupe. Pour les informations d’identification de l’utilisateur de domaine standard, vous pouvez utiliser un utilisateur existant ou en créer un, à condition qu’il ait accès aux informations d’identification gMSA.

Important

Vous devez utiliser Active Directory Domain Services ou Active Directory local. Pour le moment, vous ne pouvez pas utiliser Microsoft Entra ID pour configurer gMSA avec un cluster AKS.

Stocker les informations d’identification de l’utilisateur de domaine standard dans Azure Key Vault

Votre cluster AKS utilise les informations d’identification de l’utilisateur de domaine standard pour accéder aux informations d’identification gMSA à partir du contrôleur de domaine. Pour fournir un accès sécurisé à ces informations d’identification pour le cluster AKS, vous devez les stocker dans Azure Key Vault.

Si vous n’avez pas encore de coffre de clés Azure, créez-en un à l’aide de la commande az keyvault create.
```
az keyvault create --resource-group myResourceGroup --name myGMSAVault
```
Stockez les informations d’identification de l’utilisateur de domaine standard en tant que secret dans votre coffre de clés à l’aide de la commande az keyvault secret set. L’exemple suivant stocke les informations d’identification de l’utilisateur de domaine avec la clé GMSADomainUserCred dans le coffre de clés myGMSAVault.
```
az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
```
Remarque

Veillez à utiliser le nom de domaine complet.

Facultatif : Utilisez un réseau virtuel personnalisé avec un système DNS personnalisé

Vous devez configurer votre contrôleur de domaine par le biais du système DNS afin qu’il soit accessible par le cluster AKS. Vous pouvez configurer votre réseau et DNS en dehors de votre cluster AKS pour permettre à votre cluster d’accéder au contrôleur de domaine. Vous pouvez également utiliser Azure CNI pour configurer un réseau virtuel personnalisé avec un système DNS personnalisé sur votre cluster AKS pour fournir l’accès à votre contrôleur de domaine. Pour plus d’informations, consultez Configurer le réseau Azure CNI dans Azure Kubernetes Service (AKS).

Facultatif : Configurer plusieurs serveurs DNS

Si vous souhaitez configurer plusieurs serveurs DNS pour Windows GMSA dans votre cluster AKS, ne spécifiez pas --gmsa-dns-server ou v--gmsa-root-domain-name. Au lieu de cela, vous pouvez ajouter plusieurs serveurs DNS dans le réseau virtuel en sélectionnant DNS personnalisé et en ajoutant les serveurs DNS.

Facultatif : Utilisez votre propre identité kubelet pour votre cluster

Pour permettre au cluster AKS d’accéder à votre coffre de clés, l’identité kubelet du cluster doit accéder à votre coffre de clés. Lorsque vous créez un cluster avec une identité managée activée, une identité kubelet est créée automatiquement par défaut.

Vous pouvez accorder l’accès à votre coffre de clés pour l’identité après la création du cluster ou créer votre propre identité à utiliser avant la création du cluster en effectuant ces étapes :

Créez une identité kubelet à l’aide de la commande az identity create.
```
az identity create --name myIdentity --resource-group myResourceGroup
```
Obtenez l’ID de l’identité à l’aide de la commande az identity list et définissez-la sur une variable nommée MANAGED_ID.
```
MANAGED_ID=$(az identity list --query "[].id" -o tsv)
```
Autorisez l’identité à accéder à votre coffre de clés à l’aide de la commande az keyvault set-policy.
```
az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
```

Activer gMSA sur un nouveau cluster AKS

Créez des informations d’identification d’administrateur à utiliser lors de la création du cluster. Les commandes suivantes vous invitent à entrer un nom d’utilisateur et à le définir sur WINDOWS_USERNAME en vue d’une utilisation ultérieure dans une commande.
```
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
```
Créez un cluster AKS avec la commande az aks create, avec les paramètres suivants :
- --enable-windows-gmsa : active gMSA pour le cluster.
- --gmsa-dns-server : adresse IP du serveur DNS.
- --gmsa-root-domain-name : nom de domaine racine du serveur 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
```
Remarque
- Si vous utilisez un réseau virtuel personnalisé, vous devez spécifier l’ID de réseau virtuel à l’aide du paramètre vnet-subnet-id, et vous devrez peut-être également ajouter les paramètres docker-bridge-address, dns-service-ip et service-cidr en fonction de votre configuration.
- Si vous avez créé votre propre identité pour l’identité kubelet, utilisez le paramètre assign-kubelet-identity pour spécifier votre identité.
- Lorsque vous spécifiez les paramètres --gmsa-dns-server et --gmsa-root-domain-name , une règle de transfert DNS est ajoutée à l' kube-system/coredns ConfigMap. Cette règle transmet les requêtes DNS pour $ROOT_DOMAIN_NAME des pods vers le $DNS_SERVER.
```
$ROOT_DOMAIN_NAME:53 {
    errors
    cache 30
    log
    forward . $DNS_SERVER
}
```

Ajoutez un pool de nœuds Windows Server à l’aide de la commande az aks nodepool add.

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

Activer gMSA sur un cluster existant

Activez gMSA sur un cluster existant avec des nœuds Windows Server et des identités managées activées à l’aide de la commande 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

Accorder l’accès à votre coffre de clés pour l’identité kubelet

Remarque

Ignorez cette étape si vous avez fourni votre propre identité pour l’identité kubelet.

Accorder l’accès à votre coffre de clés pour l’identité kubelet à l’aide de la commande 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

Installer la spécification des informations d’identification gMSA

Configurez kubectl afin de vous connecter à votre cluster Kubernetes avec la commande az aks get-credentials.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Créez un fichier YAML nommé gmsa-spec.yaml et collez-y le code YAML suivant. Veillez à remplacer les espaces réservés par vos propres valeurs.

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

Remarque

AKS a mis à niveau le apiVersion de GMSACredentialSpec, de windows.k8s.io/v1alpha1 à windows.k8s.io/v1 dans la version v20230903.

Créez un fichier YAML nommé gmsa-role.yaml et collez-y le code YAML suivant.

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

Créez un fichier YAML nommé gmsa-role-binding.yaml et collez-y le code YAML suivant.

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

Appliquez les modifications de gmsa-spec.yaml, gmsa-role.yaml et gmsa-role-binding.yaml à l’aide de la commande kubectl apply.
```
kubectl apply -f gmsa-spec.yaml
kubectl apply -f gmsa-role.yaml
kubectl apply -f gmsa-role-binding.yaml
```

Vérifier l’installation de gMSA

Créez un fichier YAML nommé gmsa-demo.yaml et collez-y le code YAML suivant.

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

Appliquez les modifications de gmsa-demo.yaml à l’aide de la commande kubectl apply.
```
kubectl apply -f gmsa-demo.yaml
```

Obtenez l’adresse IP de l’exemple d’application à l’aide de la commande kubectl get service.

kubectl get service gmsa-demo --watch

Au début, EXTERNAL-IP pour le service gmsa-demo apparaît comme En attente :

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

Quand l’adresse EXTERNAL-IP passe de l’état pending à une adresse IP publique réelle, utilisez CTRL-C pour arrêter le processus de surveillance kubectl.

L’exemple de sortie suivant montre une adresse IP publique valide affectée au service :
```
gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
```
Ouvrez un navigateur web à l’adresse IP externe du service gmsa-demo.
Authentifiez-vous avec $NETBIOS_DOMAIN_NAME\$AD_USERNAME et le mot de passe, et confirmez que Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate s’affiche.

Activer GMSA sur un cluster existant

Désactivez GMSA sur un cluster existant avec des nœuds Windows Server à l’aide de la commande az aks update.
```
az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-windows-gmsa 
```

Remarque

Vous pouvez réactiver GMSA sur un cluster existant avec la commande az aks update.

Résolution des problèmes

Si la page se charge mais que vous n’êtes pas invité à vous authentifier, utilisez la commande kubectl logs POD_NAME pour afficher les journaux de votre pod et vérifiez que IIS avec authentification est prêt s’affiche.

Remarque

Les conteneurs Windows n’affichent pas les journaux sur kubectl par défaut. Pour permettre aux conteneurs Windows d’afficher les journaux, vous devez incorporer l’outil Moniteur de journaux dans votre image Windows. Pour plus d’informations, consultez Outils de conteneurs Windows.

Délai d’expiration de la connexion lors de la tentative de chargement de la page

Si vous dépassez le délai d’attente de la connexion en tentant de charger la page, vérifiez que l’exemple d’application s’exécute à l’aide de la commande kubectl get pods --watch. Parfois, l’adresse IP externe de l’exemple de service d’application est disponible avant l’exécution de l’exemple de pod d’application.

Le pod ne démarre pas et une erreur winapi-error s’affiche dans les événements pod

Si votre pod ne démarre pas après que vous avez exécuté la commande kubectl get pods --watch et attendu plusieurs minutes, utilisez la commande kubectl describe pod POD_NAME. Si vous voyez une erreur winapi-error dans les événements de pod, il s’agit probablement d’une erreur dans la configuration de vos informations d’identification gMSA. Vérifiez que toutes les valeurs de remplacement dans gmsa-spec.yaml sont correctes, réexécutez kubectl apply -f gmsa-spec.yaml et redéployez l’exemple d’application.

Étapes suivantes

Pour plus d’informations, consultez Considérations relatives aux conteneurs Windows avec Azure Kubernetes Service (AKS).

Partager via

Activer les comptes de services gérés de groupe (gMSA) pour vos nœuds Windows Server sur votre cluster Azure Kubernetes Service (AKS)

Prérequis

Configurer gMSA sur le contrôleur de domaine Active Directory

Stocker les informations d’identification de l’utilisateur de domaine standard dans Azure Key Vault

Facultatif : Utilisez un réseau virtuel personnalisé avec un système DNS personnalisé

Facultatif : Configurer plusieurs serveurs DNS

Facultatif : Utilisez votre propre identité kubelet pour votre cluster

Activer gMSA sur un nouveau cluster AKS

Activer gMSA sur un cluster existant

Accorder l’accès à votre coffre de clés pour l’identité kubelet

Installer la spécification des informations d’identification gMSA

Vérifier l’installation de gMSA

Activer GMSA sur un cluster existant

Résolution des problèmes

Aucune authentification n’est demandée lors du chargement de la page

Délai d’expiration de la connexion lors de la tentative de chargement de la page

Le pod ne démarre pas et une erreur winapi-error s’affiche dans les événements pod

Étapes suivantes

Ressources supplémentaires