Considérations concernant la gestion des identités et des accès pour AKS
Cet article fournit des considérations et des recommandations relatives à la conception pour la gestion des identités et des accès lors de l’utilisation de l’accélérateur de zone d’atterrissage lorsque vous utilisez Azure Kubernetes Service (AKS). Il existe plusieurs aspects de la gestion des identités et des accès, notamment les identités de cluster, les identités de charge de travail et l’accès des opérateurs.
Remarques relatives à la conception
- Déterminez l’identité de cluster à utiliser (identité managée ou principal de service).
- Déterminez comment authentifier l’accès au cluster : en fonction des certificats clients ou par Microsoft Entra ID.
- Choisissez un cluster multilocataire et la configuration du contrôle d’accès en fonction du rôle (RBAC) dans Kubernetes.
- Choisissez une méthode d’isolation. Les méthodes incluent l’espace de noms, la stratégie réseau (autorisée uniquement par Azure CNI), le calcul (pool de nœuds) et le cluster.
- Déterminez des rôles RBAC Kubernetes et de l’allocation de calcul par équipe d’application pour l’isolation.
- Décidez si les équipes d’applications peuvent lire d’autres charges de travail dans leurs clusters ou dans d’autres clusters.
- Déterminez les autorisations pour les rôles RBAC Azure personnalisés pour votre zone d’atterrissage AKS.
- Déterminez les autorisations nécessaires pour le rôle SRE (Site Reliability Engineering) pour permettre à ce rôle d’administrer ou de dépanner l’ensemble du cluster.
- Déterminez les autorisations nécessaires pour le SecOps.
- Déterminez les autorisations nécessaires pour le propriétaire de la zone d’atterrissage.
- Déterminez les autorisations nécessaires pour que les équipes d’applications soient déployées dans le cluster.
- Déterminez si vous avez besoin d’identités de charge de travail (Microsoft Entra Workload ID). Vous en aurez peut-être besoin pour des services tels que l’intégration d’Azure Key Vault et Azure Cosmos DB.
Recommandations de conception
- Identités de cluster.
- Utilisez votre propre identité managée pour votre cluster AKS.
- Définissez des rôles Azure RBAC personnalisés pour votre zone d’atterrissage AKS afin de simplifier la gestion des autorisations requises pour l’identité managée par le cluster.
- Accès au cluster.
- Utilisez Kubernetes RBAC avec Microsoft Entra ID pour limiter les privilèges et minimiser les privilèges d’administrateur. Cela permet de protéger la configuration et l’accès aux secrets.
- Utilisez l’intégration Microsoft Entra managée par AKS afin d’utiliser Microsoft Entra pour l’authentification et l’accès de l’opérateur et du développeur.
- Définissez les rôles RBAC et les liaisons de rôle requis dans Kubernetes.
- Utilisez les rôles Kubernetes et les liaisons de rôle aux groupes Microsoft Entra pour l’ingénierie de fiabilité des sites (SRE), SecOps et l’accès développeur.
- Envisagez d’utiliser Azure RBAC pour Kubernetes, qui permet une gestion unifiée et un contrôle d’accès entre les ressources Azure, AKS et Kubernetes. Lorsque le RBAC Azure pour Kubernetes est activé, vous n’avez pas besoin de gérer séparément les identités et les informations d’identification des utilisateurs pour Kubernetes. Les principaux Microsoft Entra sont validés exclusivement par Azure RBAC, mais les comptes de service et utilisateurs Kubernetes standard sont validés exclusivement par Kubernetes RBAC.
- Accordez à SRE un accès complet juste-à-temps, selon les besoins.
- Utiliser Microsoft Entra Workload ID pour Kubernetes. Lorsque vous implémentez cette fédération, les développeurs peuvent utiliser des comptes de service Kubernetes natifs et la fédération pour accéder aux ressources gérées par Microsoft Entra ID, telles qu’Azure et Microsoft Graph.