Bonnes pratiques relatives à l’authentification et à l’autorisation dans Azure Kubernetes Service (AKS)

Lorsque vous déployez et gérez des clusters dans Azure Kubernetes Service (AKS), vous implémentez les méthodes de gestion de l'accès aux ressources et aux services. Sans ces contrôles :

• les comptes peuvent avoir accès à des ressources et services inutiles ;
• Il peut être difficile de suivre les informations d’identification utilisées pour apporter des modifications.

Cet article aborde les pratiques recommandées qu’un opérateur de cluster peut suivre afin de gérer les accès et les identités pour les clusters AKS. Vous découvrirez comment effectuer les actions suivantes :

Utiliser Microsoft Entra ID

Conseils sur les bonnes pratiques

Déployez des clusters AKS avec l’intégration Microsoft Entra. L’utilisation de Microsoft Entra ID permet de centraliser la couche de gestion des identités. Tout changement au niveau du compte d’utilisateur ou de l’état du groupe est automatiquement mis à jour dans l’accès au cluster AKS. Étendez les utilisateurs ou les groupes au nombre minimum d'autorisations à l'aide de rôles (Roles), rôles de cluster (ClusterRoles) ou liaisons (Bindings).

Les développeurs et propriétaires d'applications de votre cluster Kubernetes doivent pouvoir accéder à différentes ressources. Kubernetes ne dispose d'aucune solution de gestion des identités qui vous permettrait de contrôler les ressources avec lesquelles les utilisateurs peuvent interagir. Vous pouvez plutôt intégrer votre cluster avec une solution d’identité existante comme Microsoft Entra ID, une solution de gestion des identités adaptée aux entreprises.

Avec des clusters intégrés Microsoft Entra dans AKS, vous créez des Roles ou ClusterRoles qui définissent des autorisations d’accès aux ressources. Vous liez ensuite les rôles aux utilisateurs ou aux groupes à partir de Microsoft Entra ID. Pour plus d'informations sur le contrôle d'accès en fonction du rôle Kubernetes (RBAC Kubernetes), consultez la section suivante. L’intégration Microsoft Entra et la façon dont vous contrôlez l’accès aux ressources sont représentées dans le diagramme suivant :

1. Le développeur s’authentifie avec Microsoft Entra ID.
2. Le point de terminaison d’émission de jeton Microsoft Entra émet le jeton d’accès.
3. Le développeur effectue une action à l’aide du jeton Microsoft Entra, par exemple kubectl create pod.
4. Kubernetes valide le jeton auprès de Microsoft Entra ID et récupère (fetch) les appartenances aux groupes du développeur.
5. Les stratégies relatives au cluster et au RBAC Kubernetes sont appliquées.
6. La requête du développeur aboutit en fonction de la validation précédente d’appartenance au groupe Microsoft Entra et du contrôle d’accès en fonction du rôle (RBAC) et des stratégies Kubernetes.

Pour créer un cluster AKS qui utilise Microsoft Entra ID, consultez Intégrer Microsoft Entra ID à AKS.

Utiliser le contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes)

Conseils sur les bonnes pratiques

Définissez les autorisations des utilisateurs ou des groupes pour l'accès aux ressources du cluster avec le RBAC Kubernetes. Créez des rôles et des liaisons qui affectent le plut petit nombre d’autorisations nécessaires. L’intégration à Microsoft Entra ID permet de mettre à jour automatiquement les changements d’état de l’utilisateur ou d’appartenance à un groupe, et de maintenir à jour l’accès aux ressources du cluster.

Dans Kubernetes, vous fournissez un contrôle d'accès granulaire aux ressources du cluster. Vous définissez les autorisations au niveau du cluster ou d'espaces de noms spécifiques. Vous déterminez les ressources qui peuvent être gérées et les autorisations associées. Puis vous appliquez ces rôles aux utilisateurs ou aux groupes avec une liaison. Pour plus d’informations sur Roles, ClusterRoles et Bindings, consultez Options d’accès et d’identité pour Azure Kubernetes Service (AKS).

Par exemple, vous créez un rôle (Role) qui accorde un accès complet aux ressources dans l’espace de noms finance-app, comme illustré dans l’exemple de manifeste YAML suivant :

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Créez ensuite un RoleBinding, puis liez-lui l’utilisateur Microsoft Entra developer1@contoso.com, comme indiqué dans le manifeste YAML suivant :

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Quand developer1@contoso.com est authentifié auprès du cluster AKS, il dispose d’autorisations complètes aux ressources dans l’espace de noms finance-app. De cette façon, vous séparez et contrôlez logiquement l’accès aux ressources. Utiliser le contrôle d’accès en fonction du rôle (RBAC) Kubernetes avec l’intégration Microsoft Entra ID.

Pour savoir comment utiliser des groupes Microsoft Entra afin de contrôler l’accès aux ressources Kubernetes à l’aide du contrôle d’accès en fonction du rôle (RBAC) Kubernetes, consultez Contrôler l’accès aux ressources de cluster à l’aide du contrôle d’accès en fonction du rôle et des identités Microsoft Entra dans AKS.

Utiliser Azure RBAC

Conseils sur les bonnes pratiques

Utilisez Azure RBAC pour définir les autorisations minimales requises pour permettre aux utilisateurs et aux groupes d'accéder aux ressources AKS dans le cadre d'un ou plusieurs abonnements.

Il existe deux niveaux d’accès nécessaires pour pleinement utiliser un cluster AKS :

• Accéder à la ressource AKS sur votre abonnement Azure.

  Ce niveau d'accès vous permet d'effectuer les opérations suivantes :

  • Contrôler la mise à l'échelle ou la mise à niveau de votre cluster à l'aide des API AKS
  • Extraire votre fichier kubeconfig

  Pour découvrir comment contrôler l’accès aux ressources AKS et au fichier kubeconfig, consultez Limiter l’accès au fichier de configuration du cluster.

• Accédez à l’API Kubernetes.

  Ce niveau d'accès est contrôlé par :

  • le RBAC Kubernetes (en général) ; ou
  • en intégrant Azure RBAC à AKS pour l'autorisation Kubernetes.

  Pour découvrir comment accorder des autorisations à l’API Kubernetes de façon granulaire à l’aide d’Azure RBAC, consultez Utiliser Azure RBAC pour l’autorisation Kubernetes.

Utiliser des identités managées par pod

N'utilisez pas d'informations d'identification fixes au sein de pods ou d'images conteneurs, car elles présentent un risque d'exposition ou d'abus. Utilisez plutôt des identités de pod pour demander automatiquement un accès à l’aide de Microsoft Entra ID.

Pour accéder à d’autres ressources Azure, comme Azure Cosmos DB, Key Vault ou Stockage Blob, le pod a besoin d’informations d’identification d’authentification. Vous pouvez définir des informations d’identification d’authentification avec l’image conteneur ou les injecter en tant que secret Kubernetes. Dans les deux cas, vous devez les créer et les attribuer manuellement. Généralement, ces informations d'identification sont réutilisées entre les pods et ne font pas l'objet d'une rotation régulière.

Les identités managées par pod (préversion) des ressources Azure vous permettent de demander automatiquement un accès aux services par le biais de Microsoft Entra ID. Les identités managées par pod sont actuellement disponibles en préversion pour AKS. Reportez-vous à la documentation Utiliser des identités managées par pod Microsoft Entra dans Azure Kubernetes Service (préversion) pour commencer.

L’identité managée par pod Microsoft Entra (préversion) prend en charge deux modes d’opération :

• Mode standard : dans ce mode, les 2 composants suivants sont déployés sur le cluster AKS :

  • Managed Identity Controller (MIC) : contrôleur Kubernetes qui surveille les modifications apportées aux pods, AzureIdentity et AzureIdentityBinding via le serveur d’API Kubernetes. Lorsqu’il détecte une modification pertinente, le MIC ajoute ou supprime AzureAssignedIdentity en fonction des besoins. Plus précisément, quand un pod est planifié, le MIC affecte l’identité managée sur Azure au groupe de machines virtuelles identiques sous-jacent que le pool de nœuds utilise au cours de la phase de création. Quand tous les pods utilisant l’identité sont supprimés, il supprime l’identité du groupe de machines virtuelles identiques du pool de nœuds, sauf si la même identité managée est utilisée par d’autres pods. Le MIC effectue des actions similaires quand AzureIdentity ou AzureIdentityBinding sont créés ou supprimés.

  • Node Managed Identity (NMI) : pod qui s’exécute en tant que DaemonSet sur chaque nœud du cluster AKS. NMI intercepte les demandes de jeton de sécurité adressées au service de métadonnées d’instance Azure sur chaque nœud. Il redirige les requêtes vers lui-même et vérifie si le pod a accès à l’identité pour laquelle il demande un jeton, puis récupère (fetch) le jeton auprès du locataire Microsoft Entra pour le compte de l’application.

• Mode managé : dans ce mode, il n’existe que l’identité NMI. L’identité doit être affectée manuellement et gérée par l’utilisateur. Pour plus d’informations, consultez Identité des pods en mode managé. Dans ce mode, lorsque vous utilisez la commande az aks pod-identity add pour ajouter une identité de pod à un cluster Azure Kubernetes Service (AKS), elle crée AzureIdentity et AzureIdentityBinding dans l’espace de noms spécifié par le paramètre --namespace, tandis que le fournisseur de ressources AKS affecte l’identité managée spécifiée par le paramètre --identity-resource-id au groupe de machines virtuelles identiques de chaque pool de nœuds dans le cluster AKS.

Le mode managed offre les avantages suivants par rapport au mode standard :

• L’attribution d’identité sur le groupe de machines virtuelles identiques d’un pool de nœuds peut prendre entre 40 et 60 s. Dans le cas de cronjobs ou d’applications qui requièrent l’accès à l’identité et ne tolèrent pas le délai d’affectation, il est préférable d’utiliser le mode managed, car l’identité est préaffectée au groupe de machines virtuelles identiques. Procédez manuellement ou à l’aide de la commande az aks pod-identity add.
• En mode standard, le MIC requiert des autorisations en écriture sur le groupe de machines virtuelles identiques utilisé par le cluster AKS et l’autorisation Managed Identity Operator sur les identités managées affectées par l’utilisateur. Lors de l’exécution en managed mode, étant donné qu’il n’y a pas de MIC, les attributions de rôles ne sont pas requises.

Au lieu de définir manuellement des informations d’identification pour les pods, les identités managées par pod demandent un jeton d’accès en temps réel et l’utilisent uniquement pour accéder aux ressources qui leur sont attribuées. Dans AKS, eux composants gèrent les opérations pour permettre aux pods d’utiliser des identités managées :

• Le serveur NMI (Node Management Identity) est un pod qui s’exécute en tant que DaemonSet sur chaque nœud du cluster AKS. Le serveur NMI écoute les demandes adressées par les pods aux services Azure.
• Le fournisseur de ressources Azure interroge le serveur d’API Kubernetes et recherche un mappage d’identités Azure qui correspond à un pod.

Lorsque les pods demandent un jeton de sécurité à Microsoft Entra ID pour accéder à une ressource Azure, les règles de réseau redirigent le trafic vers le serveur NMI.

1. Le serveur NMI :

   • identifie les pods demandant l’accès aux ressources Azure en fonction de leur adresse distante ;
   • interroge le fournisseur de ressources Azure.

2. Le fournisseur de ressources Azure vérifie les mappages d'identité Azure dans le cluster AKS.

3. Le serveur NMI demande un jeton d’accès à Microsoft Entra ID en fonction du mappage d’identité du pod.

4. Microsoft Entra ID fournit un jeton d’accès au serveur NMI, qui est retourné au pod.

   • Ce jeton d’accès peut alors être utilisé par le pod pour demander l’accès à des ressources dans Azure.

Dans l’exemple suivant, un développeur crée un pod qui utilise une identité managée pour demander l’accès à Azure SQL Database :

1. L’opérateur du cluster crée un compte de service pour mapper les identités lorsque les pods demandent l’accès aux ressources.
2. Le serveur NMI est déployé pour relayer les requêtes de pod, avec le fournisseur de ressources Azure, des jetons d’accès à Microsoft Entra ID.
3. Un développeur déploie un pod avec une identité managée qui demande un jeton d’accès par le biais du serveur NMI.
4. Le jeton est retourné au pod et utilisé pour accéder à Azure SQL Database

Pour utiliser des identités managées par pod, consultez Utiliser des identités managées par pod Microsoft Entra dans Azure Kubernetes Service (préversion).

Étapes suivantes

Dans cet article, nous avons traité des bonnes pratiques relatives à l’authentification et à l’autorisation pour votre cluster et vos ressources. Pour implémenter quelques-unes de ces bonnes pratiques, consultez les articles suivants :

• Intégrer Microsoft Entra ID à AKS
• Utiliser des identités managées par pod Microsoft Entra dans Azure Kubernetes Service (préversion)

Pour plus d’informations sur les opérations liées aux clusters dans AKS, consultez les bonnes pratiques suivantes :

• Multilocation et isolation de cluster
• Fonctionnalités de base du planificateur Kubernetes
• Fonctionnalités avancées du planificateur Kubernetes