Параметры доступа и удостоверения для Azure Kubernetes Service (AKS)

Область применения: ✔️ AKS Automatic ✔️ AKS Standard

AKS использует идентификацию в пяти отдельных сценариях. Каждый сценарий отвечает на другой вопрос и имеет собственную модель конфигурации.

Для большинства производственных рабочих нагрузок AKS рекомендуется по умолчанию использовать AKS Automatic, поскольку он изначально включает базовую платформу, готовую к промышленной эксплуатации, в том числе параметры по умолчанию, связанные с идентификацией, при этом сохраняется та же модель идентификации AKS, описанная в этой статье.

В этой статье кратко рассматривается каждый сценарий, объясняется, как это руководство соотносится с AKS Automatic и AKS Standard, а также приводятся ссылки на подробную документацию.

Пять сценариев идентификации в AKS

Состояние идентификации в AKS Automatic и AKS Standard

Пять сценариев идентификации в этой статье применяются как к AKS Automatic, так и к AKS Standard. Главное различие — в подходе к эксплуатации:

• AKS Automatic предлагает больше предварительно настроенных параметров удостоверений и безопасности по умолчанию.
• AKS Standard предоставляет больше ручного управления и требует дополнительных вариантов настройки.

Используйте AKS Automatic в качестве отправной точки по умолчанию для большинства рабочих нагрузок и используйте AKS Standard, если требуется более глубокая настраиваемая конфигурация платформы.

Общие сведения об AKS Automatic см. в статье Введение в Azure Kubernetes Service (AKS) Automatic.

Сравнение моделей управления удостоверениями в AKS Automatic и AKS Standard

Остальная часть этой статьи содержит краткую ориентацию на каждый сценарий.

А. Проверка подлинности на уровне управления Kubernetes

Проверка подлинности на уровне управления Kubernetes устанавливает удостоверение пользователя или субъекта-службы, вызывающего сервер API Kubernetes. AKS поддерживает:

• Microsoft Entra ID (рекомендуется): используйте учетные записи и группы Entra ID для входа в кластер. Интеграция Microsoft Entra подготавливает и меняет интеграцию от вашего имени. Сведения о включении см. в разделе "Использование интеграции Microsoft Entra".
• Локальные учетные записи: встроенный сертификат администратора кластера, который позволяет обойти Entra ID. Рекомендуется отключить локальные учетные записи в рабочей среде. См. раздел "Управление локальными учетными записями".
• Внешние поставщики удостоверений: Используйте поставщика удостоверений, совместимого с OIDC, отличного от Microsoft Entra ID. См. проверку подлинности внешнего поставщика удостоверений.

Для большинства рабочих нагрузок начните с автоматической интеграции AKS и Microsoft Entra.

Подробные сведения о том, как AKS выполняет проверку подлинности запросов API Kubernetes, см. в основных понятиях проверки подлинности кластера.

B. Авторизация уровня управления Kubernetes

После проверки подлинности вызывающего объекта в API Kubernetes AKS авторизует запрос с помощью одной (или обоих) моделей:

• Kubernetes RBAC: собственная модель Role, ClusterRole и RoleBinding Kubernetes, обрабатываемая API-сервером. Разрешения существуют в кластере в виде объектов Kubernetes.
• Авторизация Microsoft Entra ID: вебхук авторизации AKS делегирует принятие решений об авторизации службе Microsoft Entra ID с использованием назначений ролей Azure. Назначения dataActions ролей Azure RBAC поддерживаются для всех стандартных ресурсов API Kubernetes, а назначения ролей с условиями Azure ABAC поддерживаются для пользовательских ресурсов. Централизованно управляйте разрешениями в Microsoft Entra ID, чтобы управлять множеством кластеров с помощью одного назначения роли на уровне подписки, группы управления или группы ресурсов.

В AKS Automatic Azure RBAC для авторизации Kubernetes предварительно настроена как часть исходной конфигурации по умолчанию, готовой к промышленной эксплуатации.

Сравнение и руководство по использованию каждой модели см. в концепциях авторизации кластера.

В. Авторизация ресурсов AKS (Azure Resource Manager)

Помимо авторизации вызовов API Kubernetes, необходимо также авторизовать операции уровня Azure в самом ресурсе AKS. Наиболее распространенным примером является управление тем, кто может получить доступ к кластеру kubeconfig, что представляет собой самостоятельную операцию Azure Resource Manager, которую можно тонко регулировать с помощью Azure RBAC. Эта операция использует стандартную Azure RBAC для Microsoft.ContainerService поставщика ресурсов, отличается от авторизации API Kubernetes и применяется так же к AKS Automatic и AKS Standard. Дополнительные сведения см. в разделе Ограничение доступа к файлу конфигурации кластера и в Встроенные роли Azure.

D. Идентификация кластера (кластер → Azure)

Кластеры AKS используют управляемые удостоверения Azure для действий с ресурсами Azure от вашего имени, например для создания подсистем балансировки нагрузки, подключения дисков или извлечения образов из реестра контейнеров Azure. Основные идентичности:

• Удостоверение плоскости управления: используется плоскостью управления кластером для управления ресурсами Azure, относящимися к кластеру.
• Удостоверение Kubelet: используется kubelet на каждом узле для проверки подлинности в службах, таких как Реестр контейнеров Azure.
• Идентичность надстроек/расширений: Некоторые надстройки и расширения AKS используют собственные управляемые идентичности.

AKS Automatic сохраняет ту же модель удостоверения, одновременно упрощая настройку за счёт предварительно настроенных параметров по умолчанию для рабочей среды.

Дополнительные сведения о каждом типе удостоверения и использовании назначаемых системой удостоверений и удостоверений, назначенных пользователем, см. в разделе "Управляемые удостоверения" в AKS.

Е. Удостоверение рабочей нагрузки (pod → Azure)

Удостоверение рабочей нагрузки позволяет контейнерам, работающим в вашем кластере AKS, выполнять проверку подлинности в Azure-службах, защищенных с помощью Microsoft Entra (таких как Key Vault, Storage или Cosmos DB), без хранения секретов в кластере. AKS использует идентификатор рабочей нагрузки Microsoft Entra, который предоставляет маркер учетной записи службы Kubernetes, федеративно привязанный к приложению Microsoft Entra или управляемому удостоверению, назначенному пользователем.

В AKS Automatic по умолчанию предварительно настроены идентификатор рабочей нагрузки и эмитент OIDC. В AKS Standard эти возможности являются необязательными и настроены оператором.

Не используйте устаревшее управляемое пользователем удостоверение Microsoft Entra pod для новых рабочих нагрузок.

Рекомендации по принятию решений

Справочник по разрешениям службы AKS

Сведения о разрешениях Azure, которые используют AKS (удостоверение, создающее кластер, удостоверение кластера во время выполнения, дополнительные разрешения удостоверения кластера и доступ к узлу AKS), см. в справочнике по разрешениям службы AKS.

Связанный контент

• Автоматическое введение в службу Azure Kubernetes (AKS)
• Создание Azure Kubernetes Service (AKS) автоматического кластера
• Основные понятия проверки подлинности кластера
• Основные понятия авторизации кластера
• Использование авторизации идентификатора Microsoft Entra для API Kubernetes
• Управляемые удостоверения в AKS
• Обзор идентификатора рабочей нагрузки Microsoft Entra

Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:

• Кластеры и рабочие нагрузки Kubernetes и AKS
• Безопасность Kubernetes и AKS
• Виртуальные сети Kubernetes и AKS
• Хранилище Kubernetes и AKS
• Масштабирование Kubernetes и AKS