Options d’accès et d’identité pour Azure Kubernetes Service (AKS)

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

AKS utilise l’identité dans cinq scénarios distincts. Chaque scénario répond à une question différente et a son propre modèle de configuration.

Pour la plupart des charges de travail AKS de production, AKS Automatic est la valeur par défaut recommandée, car elle commence par une base de référence de plateforme prête pour la production, y compris les valeurs par défaut liées aux identités, tout en conservant le même modèle d’identité AKS décrit dans cet article.

Cet article présente brièvement chaque scénario, explique comment les recommandations s’appliquent à AKS Automatic et AKS Standard, et renvoie vers la documentation approfondie.

Les cinq scénarios d’identité dans AKS

Scénario Question à laquelle il répond Étude approfondie des documents
A. Authentification du plan de contrôle Kubernetes Qui est l’appelant qui atteint l’API Kubernetes ? Concepts d’authentification de cluster, fournisseurs d’identité externes
B. Autorisation du plan de contrôle Kubernetes Qu’est-ce que l’appelant est autorisé à faire une fois authentifié auprès de l’API Kubernetes ? Concepts d’autorisation du cluster
Chapitre C. Autorisation de ressource AKS (Azure Resource Manager) Qui peut effectuer des opérations au niveau Azure sur la ressource AKS, telles qu'extraire kubeconfig? Limiter l’accès au fichier de configuration de cluster, rôles intégrés Azure
D. Identité de cluster (cluster → Azure) Comment le cluster AKS agit-il sur Azure pour gérer les ressources en votre nom ? Identités managées dans AKS
E. Identité de la charge de travail (pod → Azure) Comment les pods s’authentifient-ils auprès des services Azure tels que Key Vault ou Storage ? Vue d’ensemble de l’identifiant de charge de travail Microsoft Entra

Posture d’identité dans AKS Automatic et AKS Standard

Les cinq scénarios d’identité de cet article s’appliquent à AKS Automatic et AKS Standard. La principale différence est la posture opérationnelle :

  • AKS Automatic fournit des valeurs par défaut d’identité et de sécurité préconfigurées.
  • AKS Standard fournit un contrôle manuel et nécessite davantage de choix de configuration.

Utilisez AKS Automatic comme point de départ par défaut pour la plupart des charges de travail de production et utilisez AKS Standard lorsque vous avez besoin d’une configuration de plateforme personnalisée plus approfondie.

Pour obtenir une vue d’ensemble d’AKS Automatic, consultez Présentation de Azure Kubernetes Service (AKS) Automatique.

Comparaison de la posture en matière d’identité entre AKS Automatic et AKS Standard

Zone d’identification Posture automatique AKS Niveau standard d’AKS Learn more
Authentification de l’API Kubernetes Valeurs par défaut orientées production avec intégration Microsoft Entra comme modèle recommandé Configurable, notamment les comptes locaux et les options d’intégration à Entra Concepts d’authentification du cluster
Autorisation de l’API Kubernetes Azure RBAC pour l’autorisation de Kubernetes est préconfigurée Modèle d’autorisation privilégiant d’abord les comptes locaux sélectionné par la configuration du cluster Concepts d’autorisation du cluster
Autorisation de ressource AKS Utilise le modèle RBAC standard Azure sur les opérations de ressources AKS Utilise le modèle RBAC standard Azure sur les opérations de ressources AKS Contrôler l’accès kubeconfig
Identité du cluster Utilise le modèle d’identité managée avec les valeurs par défaut de la base de référence de production Utilise le modèle d’identité managée avec une configuration sélectionnée par l’opérateur Identités managées dans AKS
Identité de la charge de travail L’identité de charge de travail et l’émetteur OIDC sont préconfigurés Facultatif et configuré par opérateur Vue d’ensemble de l’identité de la charge de travail

Le reste de cet article donne une brève orientation à chaque scénario.

A. Authentification du plan de contrôle Kubernetes

L’authentification du plan de contrôle Kubernetes établit l’identité d’un utilisateur ou d’un principal de service appelant le serveur d’API Kubernetes. AKS prend en charge :

  • Microsoft Entra ID (recommandé) : utilisez Entra ID identités et groupes pour vous connecter au cluster. Microsoft Entra integration provisionne et met à jour l’intégration en votre nom. Pour activer, consultez Utiliser l’intégration de Microsoft Entra.
  • Comptes locaux : certificat d’administrateur de cluster intégré qui contourne Entra ID. Nous vous recommandons de désactiver les comptes locaux en production. Consultez Gérer les comptes locaux.
  • Fournisseurs d’identité externes : utilisez un fournisseur d’identité conforme à OIDC autre que Microsoft Entra ID. Consultez l’authentification du fournisseur d’identité externe.

Pour la plupart des charges de travail de production, commencez par l’intégration d’AKS Automatic et Microsoft Entra.

Pour une vue d’ensemble de la façon dont AKS authentifie les demandes d’API Kubernetes, consultez les concepts d’authentification de cluster.

B. Autorisation du plan de contrôle Kubernetes

Une fois qu’un appelant est authentifié auprès de l’API Kubernetes, AKS autorise la requête à l’aide d’un (ou des deux) de deux modèles :

  • Le RBAC de Kubernetes: le modèle natif de Kubernetes Role, ClusterRole et RoleBinding, évalué par le serveur d’API. Les autorisations résident dans le cluster en tant qu’objets Kubernetes.
  • Autorisation Microsoft Entra ID : un webhook d’autorisation d’AKS délègue les décisions d’autorisation à Microsoft Entra ID à l’aide des attributions de rôles Azure. Les attributions de rôles RBAC Azure avec dataActions sont prises en charge pour toutes les ressources d'API Kubernetes standard, et les attributions de rôles avec des conditions Azure ABAC sont prises en charge pour les ressources personnalisées. Gérez les autorisations de manière centralisée dans Microsoft Entra ID pour régir de nombreux clusters à partir d’une attribution de rôle unique au niveau de l’abonnement, du groupe d’administration ou de l’étendue du groupe de ressources.

Dans AKS Automatic, Azure RBAC pour l’autorisation de Kubernetes est préconfiguré dans le cadre de la configuration par défaut prête pour la production.

Pour obtenir une comparaison et des conseils sur l’utilisation de chaque modèle, consultez les concepts d’autorisation du cluster.

Chapitre C. Autorisation de ressource AKS (Azure Resource Manager)

Outre l’autorisation des appels à l’API Kubernetes, vous devez également autoriser les opérations au niveau Azure sur la ressource AKS elle-même. L’exemple le plus courant consiste à contrôler qui peut extraire les données d’un kubeconfigcluster, qui est une opération Azure Resource Manager autonome que vous pouvez régir de manière granulaire avec Azure RBAC. Cette opération utilise le RBAC standard Azure par rapport au Microsoft.ContainerService fournisseur de ressources, est distincte de l’autorisation de l’API Kubernetes et s’applique de la même façon à AKS Automatic et AKS Standard. Pour plus d’informations, consultez Limiter l’accès au fichier de configuration du cluster et aux rôles intégrés dans Azure rôles intégrés.

D. Identité de cluster (cluster → Azure)

Les clusters AKS utilisent des identités managées Azure pour agir sur des ressources Azure en votre nom, par exemple pour créer des équilibreurs de charge, attacher des disques ou extraire des images à partir d’Azure Container Registry. Les identités principales sont les suivantes :

  • Identité du plan de contrôle : utilisée par le plan de contrôle du cluster pour gérer les ressources Azure du cluster.
  • Identité Kubelet : utilisée par le kubelet sur chaque nœud pour s’authentifier auprès de services tels que Azure Container Registry.
  • Identité des modules complémentaires/extensions : certains modules complémentaires et extensions AKS utilisent leurs propres identités managées.

AKS Automatic conserve ce même modèle d’identité tout en réduisant les frictions de configuration via les valeurs par défaut de production préconfigurées.

Pour plus d’informations sur chaque type d’identité et sur la façon d’utiliser les identités affectées par le système et les identités affectées par l’utilisateur, consultez Identités managées dans AKS.

E. Identité de la charge de travail (pod → Azure)

L’identité de charge de travail permet aux pods s’exécutant dans votre cluster AKS de s’authentifier auprès des services Azure protégés par Microsoft Entra (tels que Key Vault, Stockage ou Cosmos DB) sans stocker de secrets dans le cluster. AKS utilise l’ID de charge de travail Microsoft Entra, qui projette un jeton de compte de service Kubernetes fédéré à une application Microsoft Entra ou une identité managée affectée par l’utilisateur.

AKS Automatic inclut l’identité de charge de travail et l’émetteur OIDC comme valeurs par défaut préconfigurées. Dans AKS Standard, ces fonctionnalités sont facultatives et configurées par l’opérateur.

N’utilisez pas l'identité managée par pod Microsoft Entra, déconseillée pour les nouvelles charges de travail.

Guide de décision

Objectif Utiliser ces documents
Commencer par une base de référence d’identité prête pour la production pour la plupart des charges de travail Présentation d’AKS Automatic
Connecter des utilisateurs au cluster avec l’ID Microsoft Entra Activer l’intégration de Microsoft Entra
Gouverner qui peut faire quoi dans l’API Kubernetes sur de nombreux clusters Utiliser l’autorisation d’ID Microsoft Entra pour l’API Kubernetes
Restreindre l’accès à des types de ressources personnalisés spécifiques Conditions ABAC dans l'autorisation Entra ID
Définir des autorisations par cluster et par espace de noms sous forme d’objets Kubernetes Utiliser RBAC Kubernetes avec l’intégration d’Entra
Permettez au cluster de récupérer des données depuis ACR ou d'attacher des disques Identités managées dans AKS
Permettre aux pods d’accéder à Key Vault ou au stockage sans secrets Vue d’ensemble de l’identifiant de charge de travail Microsoft Entra
Restreindre les personnes pouvant télécharger le cluster kubeconfig Limiter l’accès au fichier de configuration du cluster
Créer un cluster prêt pour la production avec la configuration d’identité par défaut Créer un cluster automatique AKS

Informations de référence sur les autorisations de service AKS

Pour les autorisations Azure qu’AKS utilise (l’identité qui crée le cluster, l’identité du cluster au moment de l’exécution, les autorisations d’identité de cluster supplémentaires et l’accès au nœud AKS), consultez la référence des autorisations de service AKS.

Contenu connexe

Pour plus d’informations sur les concepts fondamentaux de Kubernetes et d’AKS, consultez les articles suivants :

  • Last updated on