Identité et accès des charges de travail Kubernetes

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 :

• Gestion des identités et des accès Microsoft Entra pour AWS
• Mappage des concepts AWS IAM aux concepts similaires dans Azure

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.

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

Amazon Elastic Kubernetes Service (EKS) fournit des options natives pour gérer la gestion des identités et des accès dans les pods Kubernetes. Ces options incluent des rôles IAM pour les comptes de service et les rôles liés au service Amazon EKS.

Rôles IAM pour les comptes de service

Les rôles IAM pour les comptes de service vous permettent d’associer des rôles IAM à des comptes de service Kubernetes. Cette association fournit des autorisations AWS aux conteneurs au sein de n’importe quel pod qui utilise le compte de service. Les avantages de l’utilisation des rôles IAM pour les comptes de service sont les suivants :

• privilège minimum: vous pouvez attribuer des autorisations IAM spécifiques à un compte de service, en veillant à ce que seuls les pods utilisant ce compte de service aient accès à ces autorisations. Cela élimine la nécessité d’accorder des autorisations étendues au rôle IAM de nœud pour tous les pods sur un nœud, ce qui offre une approche plus sécurisée et plus granulaire. En outre, cette fonctionnalité élimine le besoin de solutions tierces telles que kube2iam. Pour plus d’informations, consultez rôles IAM pour les comptes de service.

• isolation des informations d’identification: chaque conteneur d’un pod ne peut récupérer que les informations d’identification du rôle IAM associé à son compte de service respectif. Cette isolation garantit qu’un conteneur ne peut pas accéder aux informations d’identification appartenant à un autre conteneur dans un autre pod.

• d’audit : Amazon EKS tire parti de Amazon CloudTrail pour fournir l’accès et la journalisation des événements, facilitant ainsi l’audit et la conformité rétrospectives.

Pour plus d’informations sur les rôles IAM pour les comptes de service, reportez-vous à la documentation officielle .

Rôles liés au service Amazon EKS

Les rôles liés au service Amazon EKS sont des rôles IAM uniques directement liés à Amazon EKS. Ces rôles prédéfinis incluent toutes les autorisations nécessaires pour appeler les services AWS pour le compte du rôle associé. Le rôle principal lié au service pour Amazon EKS est le rôle IAM de nœud Amazon EKS .

Le nœud Amazon EKS kubelet démon utilise le rôle IAM du nœud Amazon EKS pour passer des appels d’API aux services AWS au nom du nœud. Le profil d’instance IAM et les stratégies associées fournissent des autorisations pour ces appels d’API. Cette configuration simplifie la gestion des rôles IAM pour les nœuds au sein du cluster EKS.

Pour en savoir plus sur les rôles liés au service Amazon EKS, consultez la documentation officielle .

Informations supplémentaires

Outre les rôles IAM pour les comptes de service et les rôles liés au service Amazon EKS, il existe d’autres aspects essentiels de la gestion de l’identité et de l’accès dans Amazon EKS.

1. autorisation RBAC Amazon EKS: Amazon EKS prend en charge le contrôle d’accès en fonction du rôle (RBAC), ce qui vous permet de définir des autorisations affinées pour les ressources Kubernetes au sein de votre cluster.

2. AWS Identity and Access Management (IAM): IAM fournit une solution complète de gestion des identités pour les services AWS, y compris EKS. Il vous permet de créer et de gérer des utilisateurs, des groupes et des rôles pour contrôler l’accès à vos ressources EKS.

3. groupes de sécurité Amazon EKS: Amazon EKS vous permet d’appliquer des règles de groupe de sécurité aux pods s’exécutant dans votre cluster pour contrôler le trafic entrant et sortant.

Pour plus d’informations sur la gestion de la gestion des identités et des accès dans Amazon EKS, reportez-vous à la documentation officielle d’Amazon EKS .

Identités managées du cluster AKS

Les clusters Azure Kubernetes Service (AKS) nécessitent une l’identité Microsoft Entra pour accéder aux ressources Azure telles que les équilibreurs de charge et les disques managés. Les identités managées pour les ressources Azure sont la méthode recommandée pour autoriser l’accès à partir d’un cluster AKS vers d’autres services Azure.

Qu’est-ce que les identités managées ?

Un défi courant pour les développeurs est la gestion des secrets, des informations d’identification, des certificats et des clés utilisés pour sécuriser la communication entre les services. identités managées éliminer la nécessité pour les développeurs de gérer ces informations d’identification. Les identités managées vous permettent d’authentifier votre cluster AKS sans gérer les informations d’identification ou les inclure dans votre code. Avec les identités managées, vous affectez un rôle contrôle d’accès en fonction du rôle Azure (Azure RBAC) à l’identité, lui accordant des autorisations à des ressources spécifiques dans Azure.

Voici deux types d’identités managées :

• affectée par le système . Certaines ressources Azure, telles que les machines virtuelles, vous permettent d’activer une identité managée directement sur la ressource. Lorsque vous activez une identité managée affectée par le système :

  • Un principal de service d’un type spécial est créé dans Microsoft Entra ID pour l’identité. Le principal de service est lié au cycle de vie de cette ressource Azure. Lorsque la ressource Azure est supprimée, Azure supprime automatiquement le principal de service pour vous.
  • Par conception, seule cette ressource Azure peut utiliser cette identité pour demander des jetons à partir de Microsoft Entra ID.
  • Vous autorisez l’identité managée à avoir accès à un ou plusieurs services.
  • Le nom du principal de service affecté par le système est toujours identique au nom de la ressource Azure pour laquelle il est créé. Pour un emplacement de déploiement, le nom de son identité affectée par le système est <app-name>/slots/<slot-name>.

• affectée par l’utilisateur . Vous pouvez également créer une identité managée en tant que ressource Azure autonome. Vous pouvez créer une identité managée affectée par l’utilisateur et l’affecter à une ou plusieurs ressources Azure. Lorsque vous activez une identité managée affectée par l’utilisateur :

  • Un principal de service d’un type spécial est créé dans Microsoft Entra ID pour l’identité. Le principal de service est géré séparément des ressources qui l’utilisent.
  • Les identités affectées par l’utilisateur peuvent être utilisées par plusieurs ressources.
  • Vous autorisez l’identité managée à avoir accès à un ou plusieurs services.

Pour plus d’informations sur les différences entre les deux types d’identités managées, consultez types d’identité managée.

Identités managées dans Azure Kubernetes Service (AKS)

Ces deux types d’identités managées sont similaires, car vous pouvez utiliser l’un ou l’autre type pour autoriser l’accès aux ressources Azure à partir de votre cluster AKS. La principale différence entre elles est qu’une identité managée affectée par le système est associée à une ressource Azure unique comme un cluster AKS, tandis qu’une identité managée affectée par l’utilisateur est elle-même une ressource Azure autonome. Pour plus d’informations sur les différences entre les types d’identités managées, consultez types d’identités managées dans identités managées pour les ressources Azure.

Il existe trois types d’identités managées que vous pouvez utiliser avec un cluster AKS :

1. identité managée affectée par le système : Ce type d’identité managée est associé à une seule ressource Azure, telle qu’un cluster AKS. Il existe uniquement pour le cycle de vie du cluster.

2. identité managée affectée par l’utilisateur : une identité managée affectée par l’utilisateur est une ressource Azure autonome que vous pouvez utiliser pour autoriser l’accès à d’autres services Azure à partir de votre cluster AKS. Il persiste séparément du cluster et peut être utilisé par plusieurs ressources Azure.

3. identité managée kubelet précréée : Il s’agit d’une identité affectée par l’utilisateur facultative qui peut être utilisée par le kubelet pour accéder à d’autres ressources dans Azure. Si aucune identité managée affectée par l’utilisateur n’est spécifiée pour kubelet, AKS crée une identité kubelet affectée par l’utilisateur dans le groupe de ressources de nœud.

Comment AKS utilise-t-il des identités managées ?

Lorsque vous déployez un cluster AKS, une identité managée affectée par le système est créée automatiquement. Vous pouvez également choisir de créer le cluster avec une identité managée affectée par l’utilisateur. Le cluster utilise cette identité managée pour demander des jetons à partir de l’ID Microsoft Entra, qui sont ensuite utilisés pour autoriser l’accès à d’autres ressources s’exécutant dans Azure.

En affectant un rôle RBAC Azure à l’identité managée, vous pouvez accorder à votre cluster des autorisations pour accéder à des ressources spécifiques. Par exemple, vous pouvez affecter l’identité managée à un rôle RBAC Azure qui lui permet d’accéder aux secrets dans azure Key Vault. De cette façon, vous pouvez facilement autoriser l’accès à votre cluster sans gérer les informations d’identification.

Utilisation d’identités managées dans AKS

Lorsque vous utilisez des identités managées dans AKS, vous n’avez pas besoin de provisionner ou de faire pivoter des secrets. Azure gère les informations d’identification de l’identité pour vous. Cela vous permet d’autoriser l’accès à partir de vos applications sans gérer de secrets supplémentaires.

Si vous disposez déjà d’un cluster AKS qui utilise une identité managée, vous pouvez le mettre à jour vers un autre type d’identité managée. Toutefois, notez qu’il peut y avoir un délai pendant que les composants du plan de contrôle basculent vers la nouvelle identité. Ce processus peut prendre plusieurs heures et, pendant ce temps, les composants du plan de contrôle continueront d’utiliser l’ancienne identité jusqu’à l’expiration de son jeton.

Résumé des identités managées utilisées par AKS

AKS utilise différents types d’identités managées pour activer différents services et modules complémentaires intégrés. Voici un résumé des identités managées utilisées par AKS :

Pour plus d’informations sur les identités managées dans AKS, consultez Utiliser une identité managée dans Azure Kubernetes Service.

Microsoft Entra Workload ID pour Kubernetes

'ID de charge de travail Microsoft Entra s’intègre à Kubernetes pour permettre aux charges de travail déployées sur un cluster AKS d’accéder aux ressources protégées Microsoft Entra, telles qu’Azure Key Vault et Microsoft Graph. Il utilise les fonctionnalités natives de Kubernetes pour fédérer avec des fournisseurs d’identité externes. Pour plus d’informations, consultez Utiliser l’ID de charge de travail Microsoft Entra avec Azure Kubernetes Service.

Pour utiliser l’ID de charge de travail Microsoft Entra, vous devez configurer un compte de service dans Kubernetes. Ce compte de service est ensuite utilisé par les pods pour authentifier et accéder en toute sécurité aux ressources Azure. L’ID de charge de travail Microsoft Entra fonctionne bien avec les bibliothèques clientes Azure Identity ou la collection MSAL (Microsoft Authentication Library), ainsi que l’inscription d’application.

Pour tirer pleinement parti de l’ID de charge de travail Microsoft Entra dans un cluster Kubernetes, vous devez configurer le cluster AKS pour émettre des jetons et publier un document de découverte OIDC pour la validation des jetons. Pour plus d’informations, consultez Créer un fournisseur OpenID Connect sur Azure Kubernetes Service.

Vous devez également configurer les applications Microsoft Entra pour approuver les jetons Kubernetes. Les développeurs peuvent ensuite configurer leurs déploiements pour utiliser des comptes de service Kubernetes pour obtenir des jetons, qui sont ensuite échangés pour les jetons Microsoft Entra par l’ID de charge de travail Microsoft Entra. Enfin, les charges de travail de cluster AKS peuvent utiliser ces jetons Microsoft Entra pour accéder en toute sécurité aux ressources protégées dans Azure.

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

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.

Pour plus d’informations, de documentation et d’automatisation liées à l’ID de charge de travail Microsoft Entra, reportez-vous aux ressources suivantes :

• projet open source d’identité de charge de travail Azure
• Fédération des identités de charge de travail
• Fédération Microsoft Entra Workload ID pour Kubernetes
• Fédération Microsoft Entra Workload ID avec des fournisseurs d’identité OIDC externes
• Fédération Microsoft Entra Workload ID minimale
• documentation sur l’ID de charge de travail Microsoft Entra
• Démarrage rapide de Microsoft Entra Workload ID
• exemple : Utiliser l’ID de charge de travail Microsoft Entra pour Kubernetes avec une identité managée affectée par l’utilisateur dans une application .NET Standard

Exemple de charge de travail

Un exemple de charge de travail s’exécutant sur un cluster AKS se compose d’un serveur frontal et d’un service principal. Ces services utilisent l’ID de charge de travail Microsoft Entra pour accéder aux services Azure, notamment Azure Key Vault, Azure Cosmos DB, compte stockage Azure et espace de noms Azure Service Bus. Pour configurer cet exemple de charge de travail, les conditions préalables suivantes doivent être remplies :

1. Configurez un cluster AKS avec é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 les rôles nécessaires avec les autorisations appropriées aux applications inscrites par Microsoft Entra.
6. Établissez des informations d’identification d’identité fédérée entre l’application Microsoft Entra et l’émetteur et l’objet du compte de service.
7. Déployez l’application de charge de travail sur le cluster AKS.

Flux de messages Microsoft Entra Workload ID

Dans cet exemple de charge de travail, les applications frontend et back-end acquièrent des jetons de sécurité Microsoft Entra pour accéder aux services PaaS (Platform as a Service) Azure. Le diagramme suivant illustre le flux de messages :

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 :

• Paolo Salvatori | Ingénieur des services principaux
• Martin Gjoshevski | Ingénieur service senior

Autres contributeurs :

• Laura Nicolas | Ingénieur logiciel senior
• Chad Kittel | Ingénieur logiciel principal
• Ed Price | Responsable de programme senior
• Theano Petersen | Rédacteur technique

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

Étapes suivantes

• AKS pour les professionnels Amazon EKS
• Monitoring et journalisation Kubernetes
• Sécuriser l’accès réseau à Kubernetes
• Options de stockage pour un cluster Kubernetes
• Gestion des coûts pour Kubernetes
• Gestion des nœuds et des pools de nœuds Kubernetes
• Gouvernance des clusters
• Gestion des identités et des accès Microsoft Entra pour AWS

Ressources associées

• Utiliser un principal de service avec Azure Kubernetes Service (AKS)
• Utiliser une identité managée dans Azure Kubernetes Service
• Implémenter Azure Kubernetes Service (AKS)
• Gérer l’identité et l’accès dans Microsoft Entra ID