Основные понятия проверки подлинности кластера в службе Azure Kubernetes (AKS)

В этой статье описывается, как служба Azure Kubernetes (AKS) авторизует пользователей в API Kubernetes — то есть, кто может подключиться к контрольной плоскости. Описание включает рекомендуемый путь аутентификации на основе Microsoft Entra ID и способы блокировки аварийного доступа.

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

Дополнительные сведения о других сценариях идентификации в AKS см. в следующих примерах:

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

Аутентификация на сервере API Kubernetes (узел управления)

Сам Kubernetes не предоставляет каталог идентичностей. Без внешнего поставщика удостоверений вам потребуется управлять локальными учетными данными для каждого кластера, который не масштабируется и создает пробелы в аудите.

Рекомендуется развертывать кластеры AKS с аутентификацией Microsoft Entra ID для плоскости управления. С помощью этой интеграции кластер проверяет входящие запросы API Kubernetes к идентификатору Microsoft Entra и использует удостоверение участника Entra для принятия решений о авторизации. Идентификатор Microsoft Entra централизует уровень удостоверений — любое изменение состояния пользователя или группы автоматически отражается в доступе к кластеру и включает условный доступ, многофакторную проверку подлинности и управление привилегированными удостоверениями.

Схема, показывающая интеграцию Microsoft Entra с кластерами AKS для проверки подлинности.

Сведения о настройке см. в разделе "Включить проверку подлинности идентификатора Microsoft Entra" для плоскости управления AKS. Обратите внимание на следующее:

  • Клиент Microsoft Entra, настроенный для проверки подлинности кластера, должен совпадать с клиентом подписки, содержащей кластер AKS.
  • Для неинтерактивных входов в систему или более старых kubectl версий используйте плагин kubelogin.

Внешние поставщики удостоверений (предварительная версия)

Некоторые организации нуждаются в аутентификации пользователей кластера с помощью поставщика удостоверения личности, совместимого с OIDC, кроме Microsoft Entra ID, например, GitHub, Google Workspace, Okta или локально размещенного IdP. AKS поддерживает это с помощью структурированного удостоверения подлинности, которое настраивает аутентификаторы JWT сервера API Kubernetes для проверки токенов, выданных вашим внешним поставщиком.

Используйте этот параметр только в том случае, если у вас есть строгие требования к идентификации кластера вне Microsoft Entra ID. В противном случае выберите путь идентификатора Microsoft Entra для более полной интеграции с условным доступом, многофакторной проверкой подлинности и управлением привилегированными удостоверениями.

См. общие сведения о проверке подлинности внешнего поставщика удостоверений для кластеров AKS в разделе . Сведения о настройке см. в разделе "Настройка внешних поставщиков удостоверений с помощью структурированной проверки подлинности AKS".

Отключение локальных учетных записей

Локальные учетные записи используют встроенный сертификат администратора кластера, который обходит Microsoft Entra ID. Любой вызывающий пользователь, который может получить список этих учетных данных, получает полный доступ администратора кластера без прохождения через Entra ID, что нарушает централизованный аудит, управление условным доступом и управление привилегиями. В рабочей среде отключите локальные учетные записи, чтобы весь доступ проходил через идентификатор Microsoft Entra.

Чтобы обеспечить это в большом масштабе для многих кластеров, назначьте встроенную политику Azure Кластеры служб Azure Kubernetes должны иметь отключенные локальные методы проверки подлинности на уровне подписки или группы управления. Политика проверяет или запрещает кластеры, созданные или обновленные с включенными локальными учетными записями. Полный список встроенных политик, связанных с AKS, см. в встроенных определениях политики Azure для AKS.

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

Аутентификация на узлах кластера

Режимы доступа SSH

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

  • Отключен SSH (предварительная версия): полностью блокирует доступ SSH к узлам. Рекомендуется для рабочей среды, где доступ на уровне узла регулируется только с помощью kubectl debug или других путей Kubernetes-native.
  • SSH на основе идентификатора Microsoft Entra (предварительная версия): вход в узлы с помощью удостоверений Microsoft Entra без ключей SSH для управления. Этот режим согласуется с остальной частью аутентификации кластера: он наследует условный доступ и многофакторную аутентификацию от Entra ID, поддерживает повышение уровня по требованию через Azure RBAC и Управление привилегированными идентификациями, а также централизует аудит с помощью журналов входа Entra ID.
  • Локальный пользователь SSH: традиционный доступ на основе ключа SSH. Используйте это только в том случае, если SSH на основе Entra ID не является вариантом, и регулярно меняйте ключи.

Для получения инструкций по настройке и конфигурации по режимам см. раздел "Управление доступом SSH на узлах кластера AKS".

Дальнейшие действия

  • Last updated on