Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается, как служба Azure Kubernetes (AKS) определяет, что разрешено делать подлинному вызывающему с API Kubernetes. Рассматриваются две модели авторизации, поддерживаемые AKS, и детальное управление ресурсами с использованием условий Azure ABAC.
Сведения о том, как AKS выполняет проверку подлинности вызывающих пользователей в первую очередь, см. в основных понятиях проверки подлинности кластера.
Для ознакомления со всеми четырьмя сценариями использования удостоверений в AKS см. раздел "Параметры доступа и удостоверения для AKS".
Авторизовать доступ к API Kubernetes
После проверки подлинности вызывающего абонента AKS оценивает, авторизован ли абонент для выполнения запрошенного действия. AKS поддерживает две модели авторизации для API Kubernetes:
- Управление доступом на основе ролей Kubernetes (RBAC). Собственная модель авторизации Kubernetes. Разрешения определяются как
RoleиClusterRoleобъекты и предоставляются субъектам черезRoleBindingиClusterRoleBindingобъекты, хранящиеся в каждом кластере. - Авторизация идентификатора Microsoft Entra. Веб-перехватчик авторизации AKS, который делегирует решения о авторизации идентификатору Microsoft Entra. Разрешения предоставляются в качестве назначений ролей Azure удостоверениям Entra ID и могут быть дополнительно уточнены с помощью условий Azure ABAC.
В одном кластере можно использовать обе модели. Мы рекомендуем использовать идентификацию Microsoft Entra ID в качестве метода авторизации по умолчанию и резервировать RBAC Kubernetes для тонкой настройки разрешений внутри кластера. В остальной части этого раздела объясняется, почему и когда следует использовать каждый из них.
Kubernetes RBAC
Kubernetes RBAC — это исходная модель авторизации Kubernetes. Вы создаете Role или ClusterRole объекты, предоставляющие действия (например, get, list, create) для ресурсов (например, pods, deployments), и привязываете их к субъектам (пользователям, группам или учетным записям служб) с помощью RoleBinding или ClusterRoleBinding объектов. Встроенный авторизатор RBAC сервера API Kubernetes оценивает эти привязки по каждому запросу.
Используйте RBAC Kubernetes, когда вам нужно:
- Детализированное управление доступом внутри кластера и по пространствам имен, созданное в виде манифестов Kubernetes наряду с рабочими нагрузками, которые они защищают.
- Авторизация, управляемая GitOps, находится в том же источнике истины, что и конфигурация приложения.
- Разрешения для учетных записей сервисов внутри кластера, которые рабочие нагрузки используют для вызова API Kubernetes.
Разрешения RBAC Kubernetes относятся к одному кластеру. Чтобы применить ту же политику ко многим кластерам, необходимо применить манифесты к каждому кластеру (обычно через GitOps). Используйте пользователей и группы Microsoft Entra в качестве субъектов объектов Kubernetes RoleBinding и ClusterRoleBinding, чтобы идентификации людей по-прежнему происходили из центрального каталога.
Дополнительные сведения о модели RBAC в Kubernetes см. в исходной документации RBAC Kubernetes. Сведения о настройке в AKS см. в разделе "Использование RBAC Kubernetes" с интеграцией Microsoft Entra.
Авторизация идентификатора Microsoft Entra для API Kubernetes
При авторизации с помощью Entra ID AKS развертывает веб-перехватчик, который делегирует решения об авторизации API Kubernetes через Microsoft Entra ID. Когда запрос достигает сервера API, вебхук вызывает API Entra ID, чтобы оценить назначения ролей Azure вызывающего абонента (и любые присоединенные условия ABAC) и возвращает решение о разрешении или запрете.
Авторизация Entra ID дает следующие преимущества по сравнению с управлением манифестами RBAC Kubernetes в каждом кластере:
- Единая платформа идентификации. Те же пользователи, группы и субъекты-службы Microsoft Entra, которые управляют доступом к ресурсам Azure, также управляют доступом к API Kubernetes. Нет отдельного каталога пользователей для подготовки или смены.
- Назначьте один раз, чтобы управлять множеством кластеров. Назначения ролей Azure можно осуществлять на уровне подписки, группы управления или группы ресурсов. Одно назначение роли в масштабе группы ресурсов предоставляет доступ ко всем текущим и будущим кластерам AKS в этой группе ресурсов. При использовании RBAC Kubernetes необходимо применять манифесты к каждому кластеру по отдельности.
- Условный доступ и управление привилегированными удостоверениями (PIM). Доступ к кластеру автоматически наследует существующие политики условного доступа вашей организации Entra ID, которые включают, например, многофакторную аутентификацию или ограничения на основе расположения, и может быть повышен по мере необходимости через PIM.
- Централизованный аудит. Каждое изменение назначения ролей записывается в журнале действий Azure вместе с другими изменениями ресурсов Azure, поэтому для управления доступом к кластеру используется один путь аудита.
- Детализированные пользовательские ограничения ресурсов. С помощью условий ABAC можно ограничить доступ к определенным группам и типам пользовательских ресурсов (CRD), не записывая манифесты Kubernetes RBAC для каждого кластера.
AKS предоставляет следующие встроенные роли для авторизации Entra ID.
| Роль | Description |
|---|---|
| Читатель RBAC для Службы Kubernetes в Azure | Доступ только для чтения к большинству объектов в пространстве имен. Не допускает просмотр ролей, привязок ролей или Secrets. |
| Редактор RBAC для службы Azure Kubernetes | Доступ на чтение и запись к большинству объектов в пространстве имен. Не допускает просмотр или изменение ролей или привязок ролей. |
| Администратор RBAC для службы Azure Kubernetes | Доступ на чтение и запись к большинству ресурсов в пространстве имен, а также способность создавать роли и привязки ролей в этом пространстве имен. |
| Администратор кластера RBAC для службы Azure Kubernetes | Полный контроль над каждым ресурсом в кластере во всех пространствах имен. |
Для пользовательских шаблонов разрешений можно создавать пользовательские определения ролей, предназначенные для определенных групп API Kubernetes, используя Microsoft.ContainerService действия данных поставщика ресурсов. Пошаговые примеры настройки и пользовательских ролей см. в разделе "Использование авторизации идентификатора Microsoft Entra" для API Kubernetes.
Comparison
| Функциональность | Kubernetes RBAC | Авторизация Entra ID |
|---|---|---|
| Источник идентификаций | Пользователи, группы, учетные записи служб Kubernetes | Идентификаторы Microsoft Entra ID |
| Область одного гранта | Один кластер | Ресурс, группа ресурсов, подписка или группа управления |
| Управление несколькими кластерами | Применение манифестов к каждому кластеру (обычно GitOps) | Назначение одной роли на более высоком уровне охватывает множество кластеров |
| Условный доступ / PIM | Не поддерживаются | Наследуется от Entra ID |
| Журнал аудита | Журнал аудита кластера | Журнал действий Azure |
| Фильтрация доступа по группе CRD или типу | Создание объектов с помощью CRD Role |
Использование атрибутов условий ABAC для назначения ролей |
Ограничение доступа к настраиваемым ресурсам с помощью условий ABAC
Если вы предоставляете широкий доступ на чтение через Microsoft Entra ID, но хотите ограничить, на чтение каких пользовательских ресурсов (CRD) получатель имеет права, добавьте условие Azure ABAC к назначению роли.
Без условий ABAC предоставление доступа к пользовательским ресурсам требует использования подстановочного знака, такого как Microsoft.ContainerService/managedClusters/*/read, который охватывает каждый CRD во всех кластерах в рамках области. С помощью ABAC можно установить условие, которое ограничивает доступ к определенным группам и типам CRD, например, разрешить templates.gatekeeper.sh и блокировать kyverno.io, без необходимости записи манифестов Kubernetes RBAC для каждого кластера.
Для авторизации API Kubernetes можно фильтровать доступ к пользовательским ресурсам по их группе API и типу с помощью следующих атрибутов:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Дополнительные сведения о azure ABAC см. в статье "Что такое условия назначения ролей Azure?". Пошаговые инструкции по настройке см. в разделе "Ограничение доступа к пользовательским ресурсам" с помощью условий ABAC.