Partager via

Options d’accès et d’identité pour AKS activées par Azure Arc

  • Article

S’applique à : AKS sur Azure Local, version 23H2

Vous pouvez authentifier, autoriser, sécuriser et contrôler l’accès aux clusters Kubernetes de différentes façons :

RBAC Kubernetes et RBAC Azure vous aident à sécuriser l’accès à votre cluster et à fournir uniquement les autorisations minimales requises aux développeurs et aux opérateurs.

Cet article présente les principaux concepts permettant de vous authentifier et d’affecter des autorisations dans AKS.

Contrôle RBAC Kubernetes

Le contrôle RBAC Kubernetes assure un filtrage granulaire des actions de l’utilisateur. Avec ce mécanisme de contrôle :

  • Vous affectez à des utilisateurs ou à des groupes d’utilisateurs l’autorisation de créer et de modifier des ressources, ou d’afficher des journaux à partir de charges de travail d’applications en cours d’exécution.
  • Vous pouvez limiter la portée de ces autorisations à un seul espace de noms, ou les accorder à l’ensemble du cluster AKS.
  • Vous créez des rôles pour définir des autorisations, puis affectez ces rôles aux utilisateurs avec les liaisons de rôle.

Pour plus d’informations, consultez Utilisation de l’autorisation RBAC Kubernetes.

Rôles et ClusterRoles

Rôles

Avant d’attribuer des autorisations aux utilisateurs avec RBAC Kubernetes, vous définissez les autorisations utilisateur en tant que rôle. Accordez des autorisations dans un espace de noms Kubernetes à l’aide de rôles.

Les rôles Kubernetes accordent des autorisations ; ils ne les refusent pas. Pour accorder des autorisations sur l’ensemble du cluster ou des ressources de cluster en dehors d’un espace de noms donné, vous pouvez utiliser ClusterRoles.

ClusterRoles

Un ClusterRole accorde et applique des autorisations aux ressources sur l’ensemble du cluster, et non à un espace de noms spécifique.

RoleBindings et ClusterRoleBindings

Une fois que vous avez défini des rôles pour accorder des autorisations aux ressources, vous attribuez ces autorisations RBAC Kubernetes avec un RoleBinding. Si votre cluster AKS s’intègre à Microsoft Entra ID, les RoleBindings accordent des autorisations aux utilisateurs Microsoft Entra pour effectuer des actions au sein du cluster. Voir Contrôler l’accès à l’aide de l’ID Microsoft Entra et du RBAC Kubernetes

RoleBindings

Assignez des rôles aux utilisateurs pour un espace de noms donné à l’aide de RoleBindings. Avec RoleBindings, vous pouvez séparer logiquement un cluster AKS unique, en autorisant uniquement les utilisateurs à accéder aux ressources d’application dans leur espace de noms attribué.

Pour lier des rôles dans l’ensemble du cluster ou à des ressources de cluster en dehors d’un espace de noms donné, utilisez ClusterRoleBindings.

ClusterRoleBinding

Avec un ClusterRoleBinding, vous liez des rôles à des utilisateurs et vous les appliquez aux ressources sur l’ensemble du cluster, et non à un espace de noms spécifique. Ce moyen vous permet d’accorder aux administrateurs ou aux techniciens du support technique l’accès à toutes les ressources dans le cluster AKS.

Comptes de service Kubernetes

Les comptes de service sont un des principaux types d’utilisateur dans Kubernetes. L’API Kubernetes contient et gère les comptes de service. Les informations d’identification du compte de service sont stockées en tant que secrets Kubernetes, ce qui leur permet d’être utilisés par des pods autorisés pour communiquer avec le serveur d’API. La plupart des requêtes d’API fournissent un jeton d’authentification pour un compte de service ou un compte d’utilisateur normal.

Ces comptes d’utilisateur autorisent un accès plus classique pour les développeurs et les administrateurs humains, ils se ne limitent pas seulement aux services et aux processus. Bien que Kubernetes ne fournisse pas de solution de gestion des identités pour stocker les comptes et mots de passe des utilisateurs réguliers, vous pouvez intégrer des solutions d’identité externes à Kubernetes. Pour les clusters AKS, cette solution d’identité intégrée est Microsoft Entra ID.

Pour plus d’informations sur les options d’identité dans Kubernetes, consultez l’authentification Kubernetes.

Contrôle d’accès en fonction du rôle Azure

Azure Role-based Access Control (RBAC) est un système d’autorisation basé sur Azure Resource Manager qui fournit une gestion fine des accès des ressources Azure.

Système RBAC Description
Runbook automation Kubernetes Conçu pour fonctionner sur des ressources Kubernetes dans votre cluster AKS.
Azure RBAC Conçu pour fonctionner sur des ressources dans votre abonnement Azure.

Avec le contrôle RBAC Azure, vous créez une définition de rôle qui décrit les autorisations à appliquer. Vous attribuez ensuite à un utilisateur ou à un groupe cette définition de rôle par le biais d’une attribution de rôle pour une étendue spécifique. L’étendue peut être une ressource spécifique, un groupe de ressources ou l’ensemble de l’abonnement.

Pour plus d’informations, consultez Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (Azure RBAC) ?

Il existe deux niveaux d’accès requis pour exploiter entièrement un cluster AKS Arc :

  • Accédez à la ressource AKS dans votre abonnement Azure.
    • Contrôlez la mise à l’échelle ou la mise à niveau de votre cluster à l’aide d’AKS activé par les API Azure Arc.
    • Extrayez votre administrateur, kubeconfig basé sur un certificat.
    • Extrayez votre ID Entra activé kubeconfig.
  • Accédez à l’API Kubernetes. Cet accès est contrôlé par :
    • RBAC Kubernetes ou
    • en intégrant Azure RBAC à AKS pour l'autorisation Kubernetes.

Azure RBAC pour autoriser l’accès à la ressource AKS

Avec RBAC Azure, vous pouvez fournir à vos utilisateurs (ou identités) un accès granulaire aux ressources AKS dans un ou plusieurs abonnements. Il existe trois rôles disponibles pour cette action de plan de contrôle : rôle d’administrateur de cluster Azure Kubernetes Service Arc, rôle d’utilisateur de cluster Azure Kubernetes Service Arc et rôle contributeur Azure Kubernetes Service Arc. Chaque rôle a une étendue d’autorisation différente, comme décrit dans les rôles intégrés Azure pour les conteneurs. Par exemple, vous pouvez utiliser le rôle Contributeur Azure Kubernetes Service Arc pour créer, mettre à l’échelle et mettre à niveau votre cluster. Pendant ce temps, un autre utilisateur disposant du rôle d’administrateur de cluster Azure Kubernetes Service Arc n’a l’autorisation d’extraire le kubeconfig administrateur.

Azure RBAC pour l’autorisation Kubernetes

Avec l’intégration RBAC Azure, AKS utilise un serveur webhook d’autorisation Kubernetes pour vous permettre de gérer les autorisations et attributions de ressources de cluster Kubernetes intégrées à Microsoft Entra à l’aide de la définition de rôle Azure et des attributions de rôles.

Diagramme du flux d’autorisation.

Comme illustré dans ce diagramme, lors de l’utilisation de l’intégration RBAC Azure, toutes les demandes adressées à l’API Kubernetes suivent le même flux d’authentification que décrit dans l’intégration de Microsoft Entra.

Si l’identité qui effectue la requête existe dans l’ID Microsoft Entra, Azure teams avec Kubernetes RBAC pour autoriser la demande. Si l’identité existe en dehors de l’ID Microsoft Entra (par exemple, un compte de service Kubernetes), l’autorisation reporte vers le RBAC Kubernetes normal.

Dans ce scénario, vous utilisez des mécanismes et API Azure RBAC pour affecter des rôles intégrés aux utilisateurs ou créer des rôles personnalisés, comme vous le feriez avec des rôles Kubernetes.

Grâce à cette fonctionnalité, vous accordez non seulement aux utilisateurs des autorisations pour la ressource AKS sur l’ensemble des abonnements, mais vous configurez également le rôle et les autorisations pour chacun de ces clusters contrôlant l’accès à l’API Kubernetes. Il existe quatre rôles intégrés disponibles pour cette action de plan de données, chacun avec son propre étendue d’autorisations, comme décrit dans la section rôles intégrés.

Important

Vous devez activer Azure RBAC pour l’autorisation Kubernetes avant d’effectuer l’attribution de rôle. Pour plus d’informations et des instructions pas à pas, consultez Utiliser Azure RBAC pour l’autorisation Kubernetes.

Rôles intégrés

AKS activé par Arc fournit les cinq rôles intégrés suivants. Ils sont similaires aux rôles intégrés Kubernetes avec quelques différences, telles que la prise en charge des CRD. Consultez la liste complète des actions autorisées par chaque rôle intégré Azure.

Role Description
Utilisateur de cluster Kubernetes avec Azure Arc Vous permet de récupérer le fichier kubeconfig basé sur Cluster Connect pour gérer les clusters n’importe où.
Visionneuse Kubernetes Azure Arc Autorise l’accès en lecture seule pour voir la plupart des objets dans un espace de noms.
N’autorise pas l’affichage des secrets, car l’autorisation de lecture sur les secrets permet d’accéder aux informations d’identification ServiceAccount dans l’espace de noms. Ces informations d’identification autorisent à leur tour l’accès à l’API via cette valeur ServiceAccount (forme d’escalade de privilèges).
Enregistreur Kubernetes Azure Arc Autorise l’accès en lecture/écriture pour la plupart des objets dans un espace de noms.
N’autorise pas l’affichage ou la modification des rôles ou des liaisons de rôle. Toutefois, ce rôle permet d’accéder aux secrets et aux pods en cours d’exécution en tant que valeur ServiceAccount dans l’espace de noms. Il peut donc être utilisé pour obtenir les niveaux d’accès d’API de n’importe quelle valeur ServiceAccount dans l’espace de noms.
Administrateur Kubernetes Azure Arc Autorise l’accès administrateur. Elle est destinée à être accordée dans un espace de noms via RoleBinding. Si vous l’utilisez dans RoleBinding, il autorise l’accès en lecture/écriture à la plupart des ressources d’un espace de noms, notamment la possibilité de créer des rôles et des liaisons de rôles dans l’espace de noms. Ce rôle n’autorise pas l’accès en écriture au quota de ressources ou à l’espace de noms lui-même.
Administrateur de cluster Kubernetes Azure Arc Autorise l’accès « superutilisateur » à exécuter n’importe quelle action sur n’importe quelle ressource. Lorsque vous l’utilisez dans ClusterRoleBinding, il offre un contrôle total sur chaque ressource du cluster et dans tous les espaces de noms. Lorsque vous l’utilisez dans RoleBinding, il donne un contrôle total sur chaque ressource de l’espace de noms de liaison de rôle, y compris l’espace de noms lui-même.

Intégration de Microsoft Entra

Améliorez la sécurité de votre cluster AKS avec l’intégration de Microsoft Entra. Basé sur l’expérience de gestion des identités d’entreprise, Microsoft Entra ID est un service de gestion des identités et d’annuaires multilocataire basé sur le cloud qui combine les principaux services d’annuaire, la gestion des accès aux applications et la protection des identités. Avec Microsoft Entra ID, vous pouvez intégrer des identités locales dans les clusters AKS pour fournir une source unique de sécurité et de gestion des comptes.

Organigramme montrant l’intégration d’Entra.

Avec les clusters AKS intégrés à Microsoft Entra, vous pouvez accorder aux utilisateurs ou aux groupes l’accès aux ressources Kubernetes au sein d’un espace de noms ou d’un cluster à l’autre.

  • Pour obtenir un contexte de configuration kubectl , exécutez la commande az aksarc get-credentials .
  • Lorsqu’un utilisateur interagit avec le cluster AKS à l’aide de kubectl, il est invité à se connecter avec ses informations d’identification Microsoft Entra.

Cette solution fournit une source unique pour les informations d’identification de mots de passe et de gestion des comptes utilisateur. L’utilisateur peut accéder uniquement aux ressources définies par l’administrateur du cluster Kubernetes.

L’authentification Microsoft Entra est fournie aux clusters AKS avec OpenID Connect. OpenID Connect est une couche d’identité basée sur le protocole OAuth 2.0. Pour plus d’informations sur OpenID Connect, consultez la documentation OpenID Connect. À partir du cluster Kubernetes, l’authentification par jeton webhook est utilisée pour vérifier les jetons d’authentification. L’authentification par jeton de Webhook est configurée et gérée en tant que partie du cluster AKS.

Résumé

Le tableau suivant contient un résumé de la façon dont les utilisateurs peuvent s’authentifier auprès de Kubernetes lorsque l’intégration de Microsoft Entra est activée. Dans tous les cas, la séquence de commandes est la suivante :

  1. Exécuter az login pour s’authentifier sur Azure.
  2. Exécutez az aksarc get-credentials pour télécharger les informations d’identification du cluster Kubernetes dans .kube/config.
  3. Exécutez les commandes kubectl.
    • La première commande peut déclencher l’authentification basée sur un navigateur pour s’authentifier auprès du cluster Kubernetes, comme décrit dans le tableau suivant.
Description Octroi de rôle requis Groupes Microsoft Entra de l’administrateur de cluster Quand utiliser
Connexion d’administrateur à l’aide du certificat client Rôle d’administrateur de cluster Azure Kubernetes Service Arc. Ce rôle permet az aksarc get-credentials d’être utilisé avec l’indicateur--admin, qui télécharge un certificat d’administrateur de cluster non Microsoft Entra dans le fichier .kube/config de l’utilisateur. Il s’agit de la seule finalité du rôle d’administrateur Azure Kubernetes. n/a Si vous êtes bloqué et n’avez pas accès à un groupe Microsoft Entra valide avec accès à votre cluster.
ID Microsoft Entra avec des RoleBindings manuels (cluster) Rôle d’utilisateur du cluster Azure Kubernetes Service Arc. Le rôle Utilisateur permet az aksarc get-credentials d’être utilisé sans l’indicateur --admin . Il s’agit de la seule finalité du rôle d’utilisateur du cluster Azure Kubernetes Service.) Le résultat, sur un cluster Microsoft Entra ID, est le téléchargement d’une entrée vide dans .kube/config, qui déclenche l’authentification basée sur le navigateur lorsqu’elle est utilisée pour la première fois par kubectl. Étant donné que l’utilisateur n’est pas dans un groupe d’administrateurs de cluster, ses droits sont entièrement contrôlés par les rôles RoleBindings ou ClusterRoleBindings configurés par les administrateurs de cluster. Les RoleBindings (Cluster) désignent les utilisateurs Microsoft Entra ou les groupes Microsoft Entra comme sujets. Si aucune liaison de ce type n’a été configurée, l’utilisateur ne peut pas excuter les commandes kubectl . Si vous souhaitez un contrôle d’accès affiné et que vous n’utilisez pas Azure RBAC pour l’autorisation Kubernetes. Notez que l’utilisateur qui configure les liaisons doit se connecter à l’aide de l’une des autres méthodes répertoriées dans ce tableau.
ID Microsoft Entra par membre du groupe Microsoft Entra administrateur de cluster (défini à l’aide --aad-admin-group-object-ids d’un indicateur dans Azure CLI) Identique à la précédente. L’utilisateur est membre d’un des groupes répertoriés ici. AKS génère automatiquement une liaison ClusterRoleBinding qui lie tous les groupes répertoriés au rôle de Kubernetes cluster-admin. Ainsi, les utilisateurs de ces groupes peuvent exécuter toutes les commandes kubectl comme cluster-admin. Si vous souhaitez accorder aux utilisateurs des droits d’administrateur complets et n’utilisez pas Azure RBAC pour l’autorisation Kubernetes.
ID Microsoft Entra avec RBAC Azure pour l’autorisation Kubernetes Deux rôles :
Rôle d’utilisateur du cluster Azure Kubernetes Service Arc (comme décrit précédemment).
Un des rôles Kubernetes Azure Arc décrits précédemment ou votre propre alternative personnalisée.		 Le champ Rôles d’administrateur sous l’onglet Configuration n’est pas pertinent lorsque l’autorisation Azure RBAC pour Kubernetes est activée. Vous utilisez Azure RBAC pour l’autorisation Kubernetes. Cette approche vous offre un contrôle affiné, sans avoir à configurer de liaisons RoleBindings ou ClusterRoleBindings.

Étapes suivantes