Modifier

Partager via

Identité et accès des charges de travail Kubernetes

Microsoft Entra ID
Azure Kubernetes Service (AKS)

Cet article décrit comment Amazon Elastic Kubernetes Service (Amazon EKS) et Azure Kubernetes Service (AKS) fournissent une identité aux charges de travail Kubernetes pour leur permettre d’accéder à des services de plateforme cloud. Pour obtenir une comparaison détaillée d’Amazon Web Services (AWS) Identity and Access Management (IAM) et de Microsoft Entra ID, consultez :

Ce guide explique comment les clusters AKS, les services intégrés et les modules complémentaires utilisent des identités managées pour accéder aux ressources Azure telles que les équilibreurs de charge et les disques managés. L’article montre également comment utiliser Microsoft Entra Workload ID pour permettre aux charges de travail AKS d’accéder aux ressources Azure sans avoir besoin d’une chaîne de connexion, d’une clé d’accès ou d’informations d’identification utilisateur.

Remarque

Cet article fait partie d'une série d'articles qui aide les professionnels qui connaissent Amazon EKS à comprendre Azure Kubernetes Service (AKS).

Gestion des identités et des accès Amazon EKS

Amazon EKS propose deux options natives pour appeler des services AWS à partir d’un pod Kubernetes : les rôles IAM pour les comptes de service et les rôles liés au service Amazon EKS.

Les rôles IAM pour les comptes de service associent des rôles IAM à un compte de service Kubernetes. Ce compte de service fournit des autorisations AWS aux conteneurs dans chaque pod qui utilise le compte de service. Les rôles IAM pour les comptes de service offrent les avantages suivants :

  • Privilège minimum : vous n’avez pas besoin de fournir des autorisations étendues au rôle IAM du nœud pour les pods sur ce nœud afin d’appeler des API AWS. Vous pouvez étendre des autorisations IAM à un compte de service, et seuls les pods qui utilisent ce compte de service ont accès à ces autorisations. De plus, cette fonctionnalité dispense de recourir à des solutions tierces comme kiam ou kube2iam.

  • Isolation des informations d’identification : un conteneur peut uniquement récupérer les informations d’identification du rôle IAM qui est associé au compte de service auquel il appartient. Un conteneur n’a jamais accès aux informations d’identification d’un autre conteneur qui appartient à un autre pod.

  • Vérifiabilité : Amazon CloudTrail fournit l’accès et la journalisation des événements pour faciliter l’audit rétrospectif.

Les rôles liés au service Amazon EKS sont des rôles IAM uniques qui sont directement liés à Amazon EKS. Prédéfinis par Amazon EKS, les rôles liés au service incluent toutes les autorisations requises pour appeler d’autres services AWS pour le compte du rôle. Pour le rôle IAM du nœud Amazon EKS, le démon kubelet du nœud Amazon EKS appelle les API AWS pour le compte du nœud. Les nœuds obtiennent des autorisations pour ces appels d’API à partir d’un profil d’instance IAM et des stratégies associées.

Identités managées du cluster AKS

Un cluster AKS a besoin d’une identité pour accéder aux ressources Azure telles que les équilibreurs de charge et les disques managés. Cette identité peut être une identité gérée ou un principal de service. Par défaut, la création d’un cluster AKS crée automatiquement une identité managée affectée par le système. La plateforme Azure gère l’identité, et vous n’avez pas besoin de provisionner des secrets ni d’effectuer leur rotation. Pour plus d’informations sur les identités managées Microsoft Entra, consultez Identités managées pour les ressources Azure.

AKS ne crée pas automatiquement un principal de service. Par conséquent, si vous souhaitez utiliser un principal de service, vous devez le créer vous-même. Quand le principal de service finit par expirer, vous devez le renouveler pour maintenir le cluster opérationnel. La gestion des principaux de service ajoute de la complexité ; il est donc plus facile d’utiliser des identités managées.

Les identités managées sont essentiellement des wrappers autour des principaux de service qui simplifient la gestion. Les mêmes exigences d’autorisation s’appliquent aux principaux de service et aux identités managées. Les identités managées utilisent l’authentification par certificat. Les informations d’identification des identités managées ont une date d’expiration de 90 jours, et leur rotation s’effectue tous les 45 jours.

AKS utilise à la fois les types d’identité managée affectée par le système et affectée par l’utilisateur, et ces identités sont immuables. Lorsque vous créez ou utilisez un réseau virtuel AKS, un disque Azure attaché, une adresse IP statique, une table de routage ou une identité kubelet affectée par l’utilisateur avec des ressources externes au groupe de ressources de nœud, Azure CLI ajoute automatiquement l’attribution de rôle.

Si vous utilisez une autre méthode pour créer le cluster AKS, par exemple un modèle Bicep, un modèle Azure Resource Manager ou un module Terraform, vous devez utiliser l’ID de principal de l’identité managée du cluster pour effectuer une attribution de rôle. L’identité du cluster AKS doit au moins avoir le rôle Contributeur de réseau sur le sous-réseau de votre réseau virtuel. Pour définir un rôle personnalisé au lieu d’utiliser le rôle intégré Contributeur de réseau, vous devez avoir les autorisations suivantes :

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Si l’identité du cluster doit accéder à une ressource existante, par exemple quand vous déployez un cluster AKS sur un réseau virtuel existant, vous devez utiliser une identité managée affectée par l’utilisateur. Si vous utilisez une identité de plan de contrôle affectée par le système, le fournisseur de ressources ne peut pas obtenir son ID de principal avant de créer le cluster. Il est donc impossible de créer les attributions de rôles appropriées avant le provisionnement du cluster.

Résumé des identités managées

AKS utilise les identités managées affectées par l’utilisateur suivantes pour les services intégrés et les modules complémentaires.

Identité Nom Cas d’utilisation Autorisations par défaut Apportez votre propre identité
Plan de contrôle Nom du cluster AKS Gère les ressources du cluster, notamment les équilibreurs de charge d'entrée et les IP publiques gérées par AKS, l'autoscaler de cluster et les pilotes Azure Disk et Azure file CSI. Rôle Contributeur pour le groupe de ressources du nœud Prise en charge
Kubelet Nom du cluster AKS - agentpool Effectue l’authentification auprès d’Azure Container Registry NA (pour Kubernetes v1.15+) Pris en charge
Composant additionnel HTTPApplicationRouting Gère les ressources réseau requises Rôle de lecteur pour le groupe de ressources de nœuds, rôle de contributeur pour la zone DNS. Non
Composant additionnel Passerelle d'application d’entrée Gère les ressources réseau requises Rôle Contributeur pour le groupe de ressources du nœud Non
Composant additionnel omsagent Envoie les métriques AKS à Azure Monitor Rôle Éditeur des métriques de surveillance Non
Composant additionnel Nœud virtuel (ACIConnector) Gère les ressources réseau requises pour Azure Container Instances Rôle Contributeur pour le groupe de ressources du nœud Non

Pour plus d’informations, consultez Utiliser une identité managée dans Azure Kubernetes Service.

Microsoft Entra Workload ID pour Kubernetes

Les charges de travail Kubernetes nécessitent des informations d'identification d'application Microsoft Entra pour accéder aux ressources protégées Microsoft Entra, telles que Azure Key Vault et Microsoft Graph. La gestion des secrets et des informations d’identification qui sécurisent la communication entre les différents composants d’une solution constitue un défi courant pour les développeurs.

Microsoft Entra Workload ID pour Kubernetes élimine la nécessité de gérer les informations d’identification pour accéder à des services cloud comme Azure Cosmos DB, Azure Key Vault ou Stockage Blob Azure. Une application de charge de travail hébergée par AKS peut utiliser Microsoft Entra Workload ID pour accéder à un service managé Azure au moyen d’un jeton de sécurité Microsoft Entra, à la place d’informations d’identification explicites telles qu’une chaîne de connexion, un nom d’utilisateur et un mot de passe ou une clé primaire.

Comme illustré dans le diagramme suivant, le cluster Kubernetes devient un émetteur de jetons de sécurité qui envoie des jetons aux comptes de service Kubernetes. Vous pouvez configurer ces jetons pour qu’ils soient approuvés sur les applications Microsoft Entra. Les jetons peuvent ensuite être échangés contre des jetons d’accès Microsoft Entra au moyen des kits SDK Azure Identity ou de la bibliothèque d’authentification Microsoft (MSAL).

Diagramme montrant un workflow simplifié d’une identité managée de pod dans Azure.

  1. L’agent kubelet projette un jeton de compte de service vers la charge de travail à un chemin de fichier configurable.
  2. La charge de travail Kubernetes envoie le jeton de compte de service projeté et signé à Microsoft Entra ID, et demande un jeton d’accès.
  3. Microsoft Entra ID utilise un document de découverte OIDC pour vérifier l’approbation sur l’identité managée définie par l’utilisateur ou l’application inscrite, puis pour valider le jeton entrant.
  4. Microsoft Entra ID émet un jeton d’accès de sécurité.
  5. La charge de travail Kubernetes accède aux ressources Azure au moyen du jeton d’accès Microsoft Entra.

La fédération d’identité de charge de travail Microsoft Entra Workload ID pour Kubernetes est actuellement prise en charge uniquement pour les applications Microsoft Entra, mais le même modèle pourra potentiellement s’étendre aux identités managées Azure.

Pour plus d’informations, d’automatisation et de documentation sur Microsoft Entra Workload ID, consultez :

Exemple de charge de travail

L’exemple de charge de travail exécute un front-end et un service back-end sur un cluster AKS. Les services de charge de travail utilisent Microsoft Entra Workload ID pour accéder aux services Azure suivants grâce à des jetons de sécurité Microsoft Entra :

  • Azure Key Vault
  • Azure Cosmos DB
  • Compte de Stockage Azure
  • Espace de noms Azure Service Bus

Prérequis

  1. Configurez un cluster AKS avec l’émetteur OIDC activé.
  2. Installez le webhook d’admission de mutation.
  3. Créez un compte de service Kubernetes pour les charges de travail.
  4. Créez une application Microsoft Entra, comme indiqué dans le guide de démarrage rapide.
  5. Attribuez des rôles avec les autorisations appropriées aux applications inscrites Microsoft Entra nécessaires.
  6. Établissez des informations d’identification d’identité fédérée entre l’application Microsoft Entra et l’émetteur et sujet du compte de service.
  7. Déployez l’application de charge de travail sur le cluster AKS.

Flux de messages Microsoft Entra Workload ID

Les applications AKS reçoivent des jetons de sécurité pour leur compte de service de la part de l’émetteur OIDC du cluster AKS. Microsoft Entra Workload ID échange les jetons de sécurité contre des jetons de sécurité émis par Microsoft Entra, et les applications utilisent les jetons de sécurité émis par Microsoft Entra ID pour accéder aux ressources Azure.

Le diagramme suivant montre comment les applications front-end et back-end acquièrent des jetons de sécurité Microsoft Entra pour pouvoir utiliser des services PaaS (platform as a service).

Diagramme montrant un exemple d’application qui utilise l’identité de charge de travail Microsoft Entra Workload ID.

Téléchargez un fichier Visio de cette architecture.

  1. Kubernetes émet un jeton sur le pod lorsqu’il est planifié sur un nœud, en fonction des spécifications du pod ou du déploiement.
  2. Le pod envoie le jeton émis par OIDC à Microsoft Entra ID afin de demander un jeton Microsoft Entra pour le appId et la ressource spécifiques.
  3. Microsoft Entra ID vérifie l’approbation sur l’application et valide le jeton entrant.
  4. Microsoft Entra ID émet un jeton de sécurité : {sub: appId, aud: requested-audience}.
  5. Le pod utilise le jeton Microsoft Entra pour accéder à la ressource Azure cible.

Pour utiliser Microsoft Entra Workload ID de bout en bout dans un cluster Kubernetes :

  1. Vous configurez le cluster AKS pour l’émission de jetons et la publication d’un document de découverte OIDC qui permettent de valider ces jetons.
  2. Vous configurez les applications Microsoft Entra pour l’approbation des jetons Kubernetes.
  3. Les développeurs configurent leurs déploiements pour l’obtention des jetons Kubernetes à partir de comptes de service Kubernetes.
  4. L’ID de charge de travail Microsoft Entra échange les jetons Kubernetes pour des jetons Microsoft Entra.
  5. Les charges de travail de cluster AKS utilisent des jetons Microsoft Entra pour accéder à des ressources protégées telles que Microsoft Graph.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes