Rediger

Del via

Azure RBAC on Azure Arc-enabled Kubernetes clusters

  • Artikkel

Microsoft Entra ID and Azure role-based access control (Azure RBAC) let you control authorization checks on your Azure Arc-enabled Kubernetes cluster. Using Azure RBAC with your cluster gives you the benefits of Azure role assignments, such as activity logs showing changes made by users to your Azure resource.

Architecture

Diagram showing Azure RBAC architecture.

In order to route all authorization access checks to the authorization service in Azure, a webhook server (guard) is deployed on the cluster.

The apiserver of the cluster is configured to use webhook token authentication and webhook authorization so that TokenAccessReview and SubjectAccessReview requests are routed to the guard webhook server. The TokenAccessReview and SubjectAccessReview requests are triggered by requests for Kubernetes resources sent to the apiserver.

Guard then makes a checkAccess call on the authorization service in Azure to see if the requesting Microsoft Entra entity has access to the resource of concern.

If that entity has a role that permits this access, an allowed response is sent from the authorization service to guard. Guard, in turn, sends an allowed response to the apiserver, enabling the calling entity to access the requested Kubernetes resource.

If the entity doesn't have a role that permits this access, a denied response is sent from the authorization service to guard. Guard sends a denied response to the apiserver, giving the calling entity a 403 forbidden error on the requested resource.

Enable Azure RBAC on your Arc-enabled Kubernetes clusters

For detailed information about how to set up Azure RBAC and create role assignments for your clusters, see Use Azure RBAC on Azure Arc-enabled Kubernetes clusters.

Next steps