Partager via

Contrôle d’accès en fonction du rôle (RBAC) Azure sur des clusters Kubernetes avec Azure Arc

  • Article

Les types d’objets Kubernetes ClusterRoleBinding et RoleBinding permettent de définir l’autorisation dans Kubernetes en mode natif. Avec le contrôle d’accès en fonction du rôle (RBAC) Azure, vous pouvez utiliser Microsoft Entra ID et des attributions de rôles pour contrôler les vérifications des autorisations sur le cluster. Ceci permet d’utiliser les avantages des attributions de rôles Azure, comme les journaux d’activité montrant toutes les modifications de RBAC Azure apportées à une ressource Azure, avec votre cluster Kubernetes avec Azure Arc.

Architecture

Diagramme montrant l’architecture RBAC Azure.

Pour router tous les contrôles d’accès d’autorisation vers le service d’autorisation dans Azure, un serveur webhook (guard) est déployé sur le cluster.

L’apiserver du cluster est configuré pour utiliser une authentification par jeton de webhook et une autorisation webhook afin que les demandes TokenAccessReview et SubjectAccessReview soient routées vers le serveur webhook guard. Les demandes TokenAccessReview et SubjectAccessReview sont déclenchées par des demandes de ressources Kubernetes adressées à l’apiserver .

La protection effectue ensuite un appel checkAccess sur le service d’autorisation dans Azure pour voir si l’entité Microsoft Entra qui fait la demande a accès à la ressource concernée.

Si cette entité a un rôle qui permet cet accès, une réponseallowed est envoyée par le service d’autorisation au gardien. Le serveur guard, à son tour, envoie une réponse allowed à l’apiserver, ce qui permet à l’entité appelante d’accéder à la ressource Kubernetes demandée.

Si l’entité n’a pas de rôle qui autorise cet accès, une denied réponse est envoyée à partir du service d’autorisation pour la protection. Le serveur guard envoie une réponse denied à l’apiserver, notifiant à l’entité appelante une erreur 403 (interdite) sur la ressource demandée.

Étapes suivantes