Utiliser l’authentification unique Active Directory pour une connexion sécurisée au serveur d’API Kubernetes dans AKS activée par Azure Arc

  • Article

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

Vous pouvez créer une connexion sécurisée à votre serveur d’API Kubernetes dans AKS activé par Arc à l’aide des informations d’identification de l’authentification unique Active Directory (AD).

Vue d’ensemble d’AD dans AKS hybride

Sans l’authentification Active Directory, les utilisateurs doivent s’appuyer sur un fichier kubeconfig basé sur un certificat lors de la connexion au serveur d’API via la commande . Le fichier kubeconfig contient des secrets, tels que des clés privées et des certificats, qui doivent être distribués avec soin, ce qui peut présenter un risque important pour la sécurité.

En guise d’alternative à l’utilisation de kubeconfig basé sur un certificat, vous pouvez utiliser les informations d’identification SSO AD comme moyen sécurisé de vous connecter au serveur d’API. L’intégration d’AD à AKS Arc permet aux utilisateurs d’une machine windows jointe à un domaine de se connecter au serveur d’API à kubectl l’aide de leurs informations d’identification sSO. Cela évite de devoir gérer et distribuer des fichiers kubeconfig basés sur des certificats qui contiennent des clés privées.

L’intégration AD utilise kubeconfig AD, qui est différent des fichiers kubeconfig basés sur des certificats et ne contient pas de secrets. Toutefois, le fichier kubeconfig basé sur un certificat peut être utilisé à des fins de sauvegarde, telles que la résolution des problèmes, en cas de problème de connexion avec les informations d’identification Active Directory.

L’intégration AD offre un autre avantage en matière de sécurité : les utilisateurs et les groupes sont stockés sous forme d’identificateurs de sécurité (SID). Contrairement aux noms de groupe, les SID sont immuables et uniques, et ne présentent donc aucun conflit de nom.

Notes

Actuellement, la connectivité de l’authentification unique Active Directory n’est prise en charge que pour les clusters de charge de travail.

Cet article vous guide tout au long des étapes suivantes pour configurer Active Directory en tant que fournisseur d’identité et pour activer l’authentification unique via kubectl:

Avant de commencer

Avant de commencer le processus de configuration des informations d’identification d’authentification unique Active Directory, vous devez vérifier que les éléments suivants sont disponibles :

  • Le module PowerShell Aks-Hci le plus récent est installé. Si vous devez l’installer, consultez Télécharger et installer le module PowerShell AksHci.

  • L’hôte AKS est installé et configuré. Si vous devez installer l’hôte, suivez les étapes pour configurer votre déploiement.

  • Le fichier keytab peut être utilisé. S’il n’est pas disponible, suivez les étapes pour créer le compte AD du serveur d’API et le fichier Keytab.

    Notes

    Vous devez générer le fichier keytab pour un nom de principal du service (SPN) spécifique et ce SPN doit correspondre au compte AD du serveur d’API pour le cluster de charges de travail. Vous devez également vous assurer que le même SPN est utilisé tout au long du processus d’authentification AD. Le fichier keytab doit être nommé current.keytab.

  • Un compte AD du serveur d’API est disponible pour chaque cluster de charge de travail AKS.

  • L’ordinateur client doit être un ordinateur Windows joint à un domaine.

Créer une authentification Active Directory à l’aide du fichier keytab

Étape 1 : Créer le cluster de charge de travail et activer l’authentification AD

Avant d’installer l’authentification AD, vous devez d’abord créer un cluster de charge de travail AKS et activer le module complémentaire d’authentification AD sur le cluster. Si vous n’activez pas l’authentification AD lorsque vous créez le cluster, vous ne pourrez pas l’activer ultérieurement.

Ouvrez PowerShell en tant qu’administrateur et exécutez la commande suivante à l’aide du -enableADAuth paramètre de la New-AksHciCluster commande :

New-AksHciCluster -name mynewcluster1 -enableADAuth

Pour chaque cluster de charge de travail, assurez-vous qu’un seul compte AD de serveur d’API est disponible.

Pour plus d’informations sur la création du cluster de charge de travail, consultez Créer des clusters Kubernetes à l’aide de Windows PowerShell.

Étape 2 : Installer l’authentification AD

Avant de pouvoir installer l’authentification AD, vous devez installer le cluster de charges de travail et activer l’authentification AD sur le cluster. Pour installer l’authentification AD, utilisez l’une des options suivantes.

Option 1 :

Pour un cluster Azure Stack HCI ou Windows Server joint à un domaine, ouvrez PowerShell en tant qu’administrateur et exécutez la commande suivante :

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Notes

Pour SPN k8s/apiserver@CONTOSO.com, utilisez le format SPN k8s/apiserver@<realm name>. À la première tentative, spécifiez <realm name> en majuscules. Toutefois, si vous rencontrez des problèmes avec les lettres majuscules, créez le SPN avec des lettres minuscules. Kerberos respecte la casse.

Option 2 :

Si l’hôte du cluster n’est pas joint à un domaine, utilisez le nom d’utilisateur administrateur ou le nom de groupe au format SID, comme illustré dans l’exemple suivant.

Si vous utilisez un utilisateur administrateur :

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

Si vous utilisez un groupe d’administrateurs :

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

Pour rechercher le SID du compte d’utilisateur, consultez Déterminer l’identificateur de sécurité de l’utilisateur ou du groupe.

Avant de passer aux étapes suivantes, notez les éléments suivants :

  • Assurez-vous que le fichier keytab est nommé current.keytab.
  • Remplacez le SPN qui correspond à votre environnement.
  • Le -adminGroup paramètre crée une liaison de rôle correspondante pour le groupe AD spécifié avec des privilèges d’administrateur de cluster. Remplacez contoso\bob (comme indiqué dans l’option 1 ci-dessus) par le groupe ou l’utilisateur AD qui correspond à votre environnement.

Étape 3 : Tester le Webhook AD et le fichier keytab

Vérifiez que le webhook AD est en cours d’exécution sur le serveur d’API et que le fichier keytab est stocké en tant que secret Kubernetes. Pour obtenir le fichier kubeconfig basé sur un certificat pour le cluster de charge de travail, procédez comme suit :

  1. Obtenez un fichier kubeconfig basé sur un certificat à l’aide de la commande suivante. Utilisez le fichier kubeconfig pour vous connecter au cluster en tant qu’hôte local :

    Get-AksHciCredential -name mynewcluster1

  2. Exécutez kubectl sur le serveur auquel vous vous êtes connecté (à l’aide du fichier kubeconfig basé sur un certificat que vous avez créé précédemment), puis case activée le déploiement du webhook AD pour vous assurer qu’il est au format ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system

  3. Exécutez kubectl pour vérifier que le fichier keytab est déployé en tant que secret et qu’il est listé comme secret Kubernetes :

    kubectl get secrets -n=kube-system

Étape 4 : Créer le fichier kubeconfig AD

Une fois que le Webhook AD et le fichier keytab sont correctement déployés, créez le fichier kubeconfig AD. Une fois le fichier créé, copiez le fichier kubeconfig AD sur l’ordinateur client et utilisez-le pour vous authentifier auprès du serveur d’API. Contrairement au fichier kubeconfig basé sur un certificat, kubeconfig AD n’est pas un secret et peut être copié en texte brut en toute sécurité.

Ouvrez PowerShell en tant qu’administrateur et exécutez la commande suivante :

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

Étape 5 : Copier kubeconfig et d’autres fichiers sur l’ordinateur client

Vous devez copier les trois fichiers suivants du cluster de charge de travail AKS sur votre ordinateur client :

  • Copiez le fichier kubeconfig AD créé à l’étape précédente dans $env :USERPROFILE.kube\config.

  • Créez le chemin du dossier c :\adsso et copiez les fichiers suivants du cluster de charge de travail AKS sur votre ordinateur client :

    • Kubectl.exe sous $env :ProgramFiles\AksHci à c :\adsso.
    • Kubectl-adsso.exe sous $env :ProgramFiles\AksHci à c :\adsso.

    Notes

    Le fichier adsso.exe est généré sur le serveur lorsque vous exécutez l’applet de Get-AksHciCredential commande.

Étape 6 : Se connecter au serveur d’API à partir de l’ordinateur client

Une fois que vous avez effectué les étapes précédentes, utilisez vos informations d’identification d’authentification unique pour vous connecter à votre ordinateur client Windows joint à un domaine. Ouvrez PowerShell, puis essayez d’accéder au serveur d’API avec kubectl. Si l’opération se termine correctement, vous avez correctement configuré l’authentification unique AD.

Créer et mettre à jour la liaison de rôle de groupe AD

Comme indiqué à l’étape 2, une liaison de rôle par défaut avec des privilèges d’administrateur de cluster est créée pour l’utilisateur et/ou le groupe qui a été fourni lors de l’installation. La liaison de rôle dans Kubernetes définit les stratégies d’accès pour les groupes AD. Cette étape explique comment utiliser RBAC pour créer des liaisons de rôle de groupe AD dans Kubernetes et modifier des liaisons de rôle existantes. Par exemple, l’administrateur de cluster peut accorder des privilèges supplémentaires aux utilisateurs à l’aide de groupes AD (ce qui rend le processus plus efficace). Pour plus d’informations sur RBAC, consultez Utilisation de l’autorisation RBAC.

Lorsque vous créez ou modifiez d’autres entrées RBAC de groupe AD, le nom de l’objet doit avoir le préfixe microsoft :activedirectory :CONTOSO\group name . Notez que les noms doivent contenir un nom de domaine et un préfixe encadrés par des guillemets doubles.

Voici deux exemples :

Exemple 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob"

Exemple 2

L’exemple suivant montre comment créer un rôle personnalisé et une liaison de rôle pour un espace de noms avec un groupe AD. Dans l’exemple, SREGroup est un groupe préexistant dans Contoso Active Directory. Lorsque des utilisateurs sont ajoutés au groupe AD, ils reçoivent immédiatement des privilèges.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup"

Avant d’appliquer le fichier YAML, les noms de groupe et d’utilisateur doivent toujours être convertis en SID à l’aide de la commande :

kubectl-adsso nametosid <rbac.yml>

De même, pour mettre à jour un RBAC existant, vous pouvez convertir le SID en un nom de groupe convivial avant d’apporter des modifications. Pour convertir le SID, utilisez la commande :

kubectl-adsso sidtoname <rbac.yml>

Modifier le mot de passe du compte AD associé au compte du serveur d’API

Lorsque le mot de passe du compte du serveur d’API est modifié, vous devez désinstaller le module complémentaire d’authentification Active Directory et le réinstaller à l’aide des fichiers keytab actuel et précédent mis à jour.

Chaque fois que vous modifiez le mot de passe, vous devez renommer le keytab actuel (current.keytab) en previous.keytab. Ensuite, veillez à nommer le nouveau mot de passe current.keytab.

Important

Les fichiers doivent être nommés current.keytab et previous.keytab, respectivement. Les liaisons de rôle existantes ne sont pas affectées par cette modification.

Désinstaller et réinstaller l’authentification AD

Vous pouvez réinstaller l’authentification unique AD lorsque le compte du serveur d’API est modifié, lorsque le mot de passe est mis à jour ou pour résoudre une défaillance.

Pour désinstaller l’authentification Active Directory, ouvrez PowerShell en tant qu’administrateur et exécutez la commande suivante :

Uninstall-AksHciAdAuth -name mynewcluster1

Pour réinstaller l’authentification Active Directory, ouvrez PowerShell en tant qu’administrateur et exécutez la commande suivante :

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Notes

Pour éviter les temps d’arrêt si les clients ont mis en cache des tickets, le -previousKeytab paramètre n’est requis que lorsque vous modifiez le mot de passe.

Créer le compte AD du serveur API et le fichier keytab

Deux étapes sont impliquées dans la création du compte AD et du fichier keytab. Tout d’abord, créez un compte AD/utilisateur pour le serveur d’API avec le nom du principal de service (SPN) et, deuxièmement, créez un fichier keytab pour le compte AD.

Étape 1 : Créer un compte ou un utilisateur AD pour le serveur d’API

Utilisez la commande PowerShell New-ADUser pour créer un compte/utilisateur AD avec le SPN. Voici un exemple :

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

Étape 2 : Créer le fichier keytab pour le compte AD

Pour créer le fichier keytab, utilisez la commande Windows ktpass .

Voici un exemple d’utilisation de ktpass :

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Notes

Si vous voyez l’erreur DsCrackNames retournée 0x2 dans l’entrée de nom, vérifiez que le paramètre de /mapuser est sous forme mapuser DOMAIN\user, où DOMAIN est la sortie de l’écho %userdomain%.

Déterminer l’identificateur de sécurité de l’utilisateur ou du groupe

Utilisez l’une des deux options suivantes pour rechercher le SID de votre compte ou d’autres comptes :

  • Pour rechercher le SID associé à votre compte, à partir d’une invite de commandes de votre répertoire de base, tapez la commande suivante :

    whoami /user

  • Pour rechercher le SID associé à un autre compte, ouvrez PowerShell en tant qu’administrateur et exécutez la commande suivante :

    (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

Résoudre les problèmes liés aux certificats

Le webhook et le serveur d’API utilisent un certificat pour valider mutuellement la connexion TLS. Ce certificat expire au bout de 500 jours. Pour vérifier que le certificat a expiré, examiner les journaux d’un conteneur ad-auth-webhook :

kubectl logs ad-auth-webhook-xxx

Si vous constatez des erreurs de validation de certificat, suivez les étapes d’désinstallation et réinstallation du webhook, et obtenez de nouveaux certificats.

Meilleures pratiques et nettoyage

  • Utilisez un compte unique pour chaque cluster.
  • Ne réutilisez pas le mot de passe du compte du serveur d’API sur plusieurs clusters.
  • Supprimez la copie locale du fichier keytab dès que vous créez le cluster et vérifiez que les informations d’identification de SSO fonctionnent.
  • Supprimez l’utilisateur Active Directory qui a été créé pour le serveur d’API. Pour plus d’informations, consultez Remove-ADUser.

Étapes suivantes

Dans ce guide pratique, vous avez appris à configurer l’authentification AD pour vous connecter de manière sécurisée au serveur d’API avec des informations d’identification d’authentification unique. À présent, vous pouvez :