Удостоверение рабочей нагрузки Kubernetes и доступ

Microsoft Entra ID
Служба Azure Kubernetes (AKS)

В этой статье описывается, как Amazon Elastic Kubernetes Service (Amazon EKS) и Служба Azure Kubernetes (AKS) предоставляют удостоверения для рабочих нагрузок Kubernetes для доступа к облачным службам платформы. Подробное сравнение удостоверений Amazon Web Services (AWS) и управления доступом (IAM) и идентификатора Microsoft Entra см. в следующих статьях:

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

Примечание.

Эта статья является частью серии статей, которые помогают специалистам, знакомым с Amazon EKS, чтобы понять, Служба Azure Kubernetes (AKS).

Управление удостоверениями и доступом Amazon EKS

Amazon EKS имеет два собственных варианта вызова служб AWS из модуля pod Kubernetes: роли IAM для учетных записей служб и связанные с службами роли Amazon EKS.

Роли IAM для учетных записей служб связывают роли IAM с учетной записью службы Kubernetes. Эта учетная запись службы предоставляет разрешения AWS для контейнеров в любом модуле pod, использующего учетную запись службы. Роли IAM для учетных записей служб предоставляют следующие преимущества:

  • Минимальные привилегии: вам не нужно предоставлять расширенные разрешения роли IAM узла для модулей pod на этом узле для вызова API AWS. Вы можете ограничить разрешения IAM для учетной записи службы и только модули pod, использующие эту учетную запись службы, имеют доступ к этим разрешениям. Эта функция также устраняет необходимость сторонних решений, таких как kiam или kube2iam.

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

  • Возможность аудита: Amazon CloudTrail предоставляет доступ и ведение журнала событий, чтобы обеспечить ретроспективный аудит.

Связанные с службой роли Amazon EKS — это уникальные роли IAM, связанные непосредственно с Amazon EKS. Связанные с службами роли предопределяются Amazon EKS и включают все разрешения, необходимые для вызова других служб AWS от имени роли. Для роли IAM узла Amazon EKS управляющая программа amazon kubelet EKS вызывает API AWS от имени узла. Узлы получают разрешения для этих вызовов API из профиля экземпляра IAM и связанных политик.

Управляемые удостоверения кластера AKS

Кластер AKS требует удостоверения для доступа к ресурсам Azure, таким как подсистемы балансировки нагрузки и управляемые диски. Это удостоверение может быть либо управляемым удостоверением, либо субъектом-службой. По умолчанию создание кластера AKS автоматически создает управляемое удостоверение, назначаемое системой. Платформа Azure управляет удостоверением, и вам не нужно подготавливать или поворачивать секреты. Дополнительные сведения об управляемых удостоверениях Microsoft Entra см. в разделе "Управляемые удостоверения" для ресурсов Azure.

AKS не создает субъект-службу автоматически, поэтому если вы хотите использовать субъект-службу, необходимо создать его. Срок действия субъекта-службы истекает, и его необходимо продлить, чтобы сохранить работу кластера. Управление субъектами-службами упрощает использование управляемых удостоверений.

Управляемые удостоверения по сути являются оболочками вокруг субъектов-служб, упрощающих управление. Одинаковые требования к разрешениям применяются как к субъектам-службам, так и к управляемым удостоверениям. Управляемые удостоверения используют проверку подлинности на основе сертификатов. Каждый учетные данные управляемых удостоверений имеют срок действия 90 дней и сменяются через 45 дней.

AKS использует типы управляемых удостоверений, назначаемых как системой, так и пользователем. Эти удостоверения являются неизменяемыми. При создании или использовании виртуальной сети AKS, подключенного диска Azure, статического IP-адреса, таблицы маршрутов или удостоверения, назначаемого kubelet пользователем, с ресурсами за пределами группы ресурсов узла Azure CLI автоматически добавляет назначение роли.

Если вы используете другой метод для создания кластера AKS, например шаблона Bicep, шаблона Azure Resource Manager или модуля Terraform, необходимо использовать идентификатор субъекта управляемого удостоверения кластера для назначения ролей. Удостоверение кластера AKS должно иметь по крайней мере роль участника сети в подсети в виртуальной сети. Чтобы определить пользовательскую роль вместо использования встроенной роли участника сети, вам потребуется следующее разрешение:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Если удостоверение кластера должно получить доступ к существующему ресурсу, например при развертывании кластера AKS в существующей виртуальной сети, следует использовать управляемое удостоверение, назначаемое пользователем. Если вы используете удостоверение плоскости управления, назначаемого системой, поставщик ресурсов не может получить свой основной идентификатор перед созданием кластера, поэтому невозможно создать соответствующие назначения ролей перед подготовкой кластера.

Сводка управляемых удостоверений

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

Идентификация Имя. Вариант использования Разрешения по умолчанию Использование собственного удостоверения
Уровень управления Имя кластера AKS Управляет ресурсами кластера, включая подсистемы балансировки нагрузки входящего трафика и общедоступные IP-адреса, управляемые AKS, автомасштабирование кластера и драйверы CSI дисков Azure и файлов Azure Роль участника для группы ресурсов узла Поддерживается
kubelet Имя кластера AKS — agentpool Проверка подлинности с помощью Реестр контейнеров Azure NA (для Kubernetes версии 1.15+) Поддерживается
Надстройка HTTPApplicationRouting Управляет необходимыми сетевыми ресурсами. Роль читателя для группы ресурсов узла, роль участника для зоны DNS No
Надстройка Шлюз приложений входящего трафика Управляет необходимыми сетевыми ресурсами. Роль участника для группы ресурсов узла No
Надстройка omsagent Отправка метрик AKS в Azure Monitor Роль издателя метрик мониторинга No
Надстройка Виртуальный узел (ACIConnector) Управляет необходимыми сетевыми ресурсами для Экземпляры контейнеров Azure Роль участника для группы ресурсов узла No

Дополнительные сведения см. в разделе "Использование управляемого удостоверения в Служба Azure Kubernetes".

Идентификация рабочей нагрузки Microsoft Entra для Kubernetes

Для рабочих нагрузок Kubernetes требуются учетные данные приложения Microsoft Entra для доступа к защищенным ресурсам Microsoft Entra, таким как Azure Key Vault и Microsoft Graph. Распространенный вызов разработчикам заключается в управлении секретами и учетными данными для защиты обмена данными между различными компонентами решения.

Идентификация рабочей нагрузки Microsoft Entra для Kubernetes устраняет необходимость управления учетными данными для доступа к облачным службам, таким как Azure Cosmos DB, Azure Key Vault или Хранилище BLOB-объектов Azure. Приложение рабочей нагрузки, размещенное в AKS, может использовать Идентификация рабочей нагрузки Microsoft Entra для доступа к управляемой службе Azure с помощью маркера безопасности Microsoft Entra, а не явных учетных данных, таких как строка подключения, имя пользователя и пароль или первичный ключ.

Как показано на следующей схеме, кластер Kubernetes становится издателем маркеров безопасности, который выдает маркеры учетным записям службы Kubernetes. Эти маркеры можно настроить для доверенных приложений Microsoft Entra. Затем маркеры можно обменять на маркеры доступа Microsoft Entra с помощью пакетов SDK для удостоверений Azure или библиотеки проверки подлинности Майкрософт (MSAL).

Схема, показывающая упрощенный рабочий процесс для управляемого удостоверения pod в Azure.

  1. kubelet Агент проектировать маркер учетной записи службы в рабочую нагрузку по настраиваемому пути к файлу.
  2. Рабочая нагрузка Kubernetes отправляет проецируемый, подписанный маркер учетной записи службы идентификатору Microsoft Entra и запрашивает маркер доступа.
  3. Идентификатор Microsoft Entra использует документ обнаружения OIDC для проверки доверия к определяемой пользователем управляемой идентификации или зарегистрированного приложения и проверки входящего маркера.
  4. Идентификатор Microsoft Entra выдает маркер доступа к безопасности.
  5. Рабочая нагрузка Kubernetes обращается к ресурсам Azure с помощью маркера доступа Microsoft Entra.

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

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

Пример рабочей нагрузки

Пример рабочей нагрузки выполняет интерфейсную и серверную службу в кластере AKS. Службы рабочей нагрузки используют Идентификация рабочей нагрузки Microsoft Entra для доступа к следующим службам Azure с помощью маркеров безопасности Microsoft Entra:

  • Azure Key Vault
  • Azure Cosmos DB
  • Учетная запись хранения Azure
  • Пространство имен Служебной шины Azure

Необходимые компоненты

  1. Настройте кластер AKS с включенным издателем OIDC.
  2. Установите мутирующий веб-перехватчик приема.
  3. Создайте учетную запись службы Kubernetes для рабочих нагрузок.
  4. Создайте приложение Microsoft Entra, как показано в кратком руководстве.
  5. Назначьте роли с правильными разрешениями для необходимых зарегистрированных приложений Microsoft Entra.
  6. Установите федеративные учетные данные удостоверения между приложением Microsoft Entra и издателем учетной записи службы и субъектом.
  7. Разверните приложение рабочей нагрузки в кластере AKS.

поток сообщений Идентификация рабочей нагрузки Microsoft Entra

Приложения AKS получают маркеры безопасности для учетной записи службы из издателя OIDC кластера AKS. Идентификация рабочей нагрузки Microsoft Entra обменивается маркерами безопасности с маркерами безопасности, выданными идентификатором Microsoft Entra, и приложения используют маркеры безопасности, выданные идентификатором Microsoft, для доступа к ресурсам Azure.

На следующей схеме показано, как интерфейсные и внутренние приложения получают маркеры безопасности Microsoft Entra для использования служб Azure как услуга (PaaS).

Схема с примером приложения, использующего Идентификация рабочей нагрузки Microsoft Entra.

Скачайте файл Visio для этой архитектуры.

  1. Kubernetes выдает маркер pod при планировании на узле на основе спецификации pod или развертывания.
  2. Модуль pod отправляет маркер, выданный OIDC, в идентификатор Microsoft Entra, чтобы запросить маркер Microsoft Entra для конкретного appId и ресурса.
  3. Идентификатор Microsoft Entra проверяет доверие приложения и проверяет входящие маркеры.
  4. Идентификатор Microsoft Entra выдает маркер безопасности: {sub: appId, aud: requested-audience}
  5. Модуль pod использует маркер Microsoft Entra для доступа к целевому ресурсу Azure.

Чтобы использовать сквозную Идентификация рабочей нагрузки Microsoft Entra в кластере Kubernetes:

  1. Кластер AKS настроен для выдачи маркеров и публикации документа обнаружения OIDC, чтобы разрешить проверку этих маркеров.
  2. Вы настраиваете приложения Microsoft Entra для доверия к маркерам Kubernetes.
  3. Разработчики настраивают свои развертывания для использования учетных записей службы Kubernetes для получения маркеров Kubernetes.
  4. Идентификация рабочей нагрузки Microsoft Entra обменивается маркерами Kubernetes на токены Microsoft Entra.
  5. Рабочие нагрузки кластера AKS используют маркеры Microsoft Entra для доступа к защищенным ресурсам, таким как Microsoft Graph.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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