Compartir vía

RBAC de Azure en clústeres de Kubernetes habilitados para Azure Arc

  • Artículo

Los tipos de objeto ClusterRoleBinding y RoleBinding de Kubernetes ayudan a definir la autorización en Kubernetes de forma nativa. Con el control de acceso basado en roles de Azure (Azure RBAC), puede usar Microsoft Entra ID y las asignaciones de roles en Azure para controlar los controles de autorización en el clúster. Esto permite las ventajas de las asignaciones de roles de Azure, como los registros de actividad que muestran todos los cambios de RBAC de Azure en un recurso de Azure, se pueden usar con el clúster de Kubernetes habilitado para Azure Arc.

Arquitectura

Diagrama en el que se muestra la arquitectura de Azure RBAC.

Para enrutar todas las comprobaciones de acceso de autorización al servicio de autorización en Azure, se implementa un servidor de webhook (Guard) en el clúster.

El apiserver del clúster está configurado para usar la autenticación de tokens de webhook y la autorización de webhook para que las solicitudes TokenAccessReview y SubjectAccessReview se enruten al servidor de webhook de Guard. Las solicitudes TokenAccessReview y SubjectAccessReview se desencadenan cuando se envían solicitudes de recursos de Kubernetes al apiserver.

Después, Guard hace una llamada checkAccess al servicio de autorización de Azure para ver si la entidad de Microsoft Entra solicitante tiene acceso al recurso correspondiente.

Si esa entidad tiene un rol que permite este acceso, se envía una respuesta allowed del servicio de autorización que se protege. A su vez, Guard envía una respuesta allowed a apiserver, lo que permite a la entidad autora de la llamada acceso al recurso de Kubernetes solicitado.

Si la entidad tiene un rol que permite este acceso, se envía una respuesta denied del servicio de autorización que se protege. Guard envía una respuesta denied al apiserver, lo que devuelve a la entidad autora de la llamada un error 403 prohibido sobre el recurso solicitado.

Pasos siguientes