Partager via

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

  • Article

S’applique à : AKS sur Azure Local 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 activé par Arc

Sans l’authentification Active Directory, vous devez vous appuyer sur un fichier kubeconfig basé sur un certificat lorsque vous vous connectez au serveur d’API via la kubectl 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 de l’authentification unique AD comme moyen sécurisé de se connecter au serveur d’API. L’intégration d’AD à AKS Arc permet aux utilisateurs d’une machine jointe à un domaine Windows de se connecter au serveur d’API à kubectl l’aide de leurs informations d’identification d’authentification unique. 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.

Remarque

La connectivité de l’authentification unique AD est prise en charge uniquement pour les clusters de charge de travail.

Remarque

L’utilisation de groupes AD imbriqués (création d’un groupe AD au sein d’un autre groupe AD) n’est pas prise en charge.

Cet article vous guide tout au long des étapes de configuration d’Active Directory en tant que fournisseur d’identité et d’activation de 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.

    Remarque

    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 de 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 nouveau cluster, vous ne pouvez pas l’activer ultérieurement.

Ouvrez PowerShell en tant qu’administrateur et exécutez ce qui suit à 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’il existe un compte AD de serveur d’API 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 Local 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

Remarque

Pour SPN k8s/apiserver@CONTOSO.com, utilisez le format SPN k8s/apiserver@<realm name>. Lors de la première tentative, spécifiez <realm name> en majuscules. Toutefois, si vous rencontrez des problèmes avec des 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.

Utilisateur administrateur :

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

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 AD ou l’utilisateur qui correspond à votre environnement.

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

Vérifiez que le webhook AD s’exécute 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 vérifiez 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 vers $env:USERPROFILE.kube\config.

  • Créez le chemin d’accès au 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.

    Remarque

    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 les étapes précédentes effectuées, utilisez vos informations d’identification d’authentification unique pour vous connecter à votre ordinateur client joint à un domaine Windows. Ouvrez PowerShell, puis essayez d’accéder au serveur d’API avec kubectl. Si l’opération se termine correctement, vous configurez correctement 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 souhaiter 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 l’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 il s’agit d’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 un échec.

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

Remarque

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

Créer le compte AD du serveur d’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/utilisateur AD 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

Remarque

Si vous voyez l’erreur DsCrackNames retournée 0x2 dans l’entrée de nom, vérifiez que le paramètre pour /mapuser lequel se trouve le formulaire 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 de 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 :