Azure RBAC в кластерах Kubernetes с поддержкой Azure Arc (предварительная версия)

Типы объектов ClusterRoleBinding и RoleBinding в Kubernetes помогают определить собственную авторизацию в Kubernetes. С помощью управления доступом на основе ролей Azure (Azure RBAC) можно использовать идентификатор Microsoft Entra и назначения ролей в Azure для управления проверка авторизации в кластере. Это позволяет использовать преимущества назначений ролей Azure, таких как журналы действий, отображающие все изменения Azure RBAC в ресурс Azure, которые будут использоваться с кластером Kubernetes с поддержкой Azure Arc.

Внимание

Предварительные версии функций Kubernetes с поддержкой Azure Arc доступны в режиме самообслуживания после получения согласия на участие. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии функций Kubernetes с поддержкой Azure Arc предоставляются с частичной клиентской поддержкой по мере возможности.

Архитектура

Diagram showing Azure RBAC architecture.

Чтобы все проверки доступа авторизации направлялись в службу авторизации в Azure, в кластере развертывается сервер веб-перехватчика (guard).

В apiserver кластера настраивается использование проверки подлинности на основе маркеров веб-перехватчика и авторизации веб-перехватчика, поэтому запросы TokenAccessReview и SubjectAccessReview перенаправляются на сервер веб-перехватчика guard. Запросы TokenAccessReview и SubjectAccessReview инициируются запросами к ресурсам Kubernetes, отправляемыми в apiserver.

Затем Guard вызывает checkAccess службу авторизации в Azure, чтобы узнать, имеет ли запрашиваемая сущность Microsoft Entra доступ к ресурсу обеспокоенности.

Если у этой сущности есть роль, которая разрешает этот доступ, allowed ответ отправляется из службы авторизации для защиты. Сервер guard, в свою очередь, отправляет в apiserver ответ allowed, что позволяет вызывающей сущности получить доступ к запрошенному ресурсу Kubernetes.

Если у сущности нет роли, которая разрешает этот доступ, denied ответ отправляется из службы авторизации для защиты. Сервер guard отправляет в apiserver ответ denied, возвращая вызывающей сущности ошибку запрета 403 для запрошенного ресурса.

Следующие шаги