Uso de RBAC de Azure en clústeres de Kubernetes habilitado para Azure Arc (versión preliminar)

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

Importante

Las características en versión preliminar de Kubernetes habilitado para Azure Arc están disponibles en autoservicio y de manera opcional. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de Kubernetes habilitadas para Azure Arc reciben cobertura parcial del soporte al cliente en la medida de lo posible.

Architecture

Diagram showing Azure RBAC architecture.

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