Share via

RBAC Azure sur des clusters Kubernetes avec Azure Arc (préversion)

  • 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.

Important

Les fonctionnalités d’évaluation de Kubernetes avec Azure Arc sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions de Kubernetes avec Azure Arc sont, dans la mesure du possible, partiellement couvertes par le service clientèle.

Architecture

Diagram showing Azure RBAC architecture.

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