Идентификация рабочих нагрузок в Kubernetes и управление доступом

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

• Управление удостоверениями и управление доступом Microsoft Entra для AWS
• Сопоставление концепций AWS IAM с аналогичными понятиями Azure

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

Примечание.

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

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

Amazon EKS предоставляет собственные возможности для управления удостоверениями и доступом в pods Kubernetes. Эти параметры включают роли IAM для учетных записей служб и связанных со службой ролей Amazon EKS.

Роли IAM для учетных записей служб

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

• Наименьшие привилегии: Вы можете назначить определенные разрешения IAM учетной записи службы, гарантируя, что только те pods, которые используют эту учетную запись службы, имеют доступ к этим разрешениям. Эта конфигурация устраняет необходимость предоставлять расширенные разрешения роли узла IAM для всех pod на узле. Этот подход обеспечивает расширенную безопасность и детализированный контроль и устраняет необходимость в решениях партнеров, таких как kube2iam. Дополнительные сведения см. в разделе "Роли IAM" для учетных записей служб.

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

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

Дополнительные сведения см. в разделе "Роли IAM" для учетных записей служб.

Роли, связанные с сервисом Amazon EKS

Роли, связанные с службой Amazon EKS, представляют собой специальные уникальные роли IAM, которые напрямую связываются с Amazon EKS. Эти предопределенные роли включают необходимые разрешения для вызова служб AWS от имени связанной роли. Основная роль, связанная с сервисом Amazon EKS, — это роль IAM узла Amazon EKS.

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

Дополнительные сведения см. в статье "Использование связанных служб ролей для Amazon EKS".

Дополнительные сведения об управлении удостоверениями и доступом

Помимо ролей IAM для учетных записей сервисов и ролей, связанных с сервисом Amazon EKS, к другим важным аспектам управления идентификацией и доступом в Amazon EKS относятся:

• Авторизация Amazon EKS RBAC: Amazon EKS поддерживает управление доступом на основе ролей (RBAC). Используйте эту функцию для определения подробных разрешений для ресурсов Kubernetes в кластере.

• AWS IAM: IAM предоставляет комплексное решение для управления удостоверениями для служб AWS, включая EKS. Используйте IAM для создания пользователей, групп и ролей для управления доступом к ресурсам EKS и управления ими.

• Группы безопасности Amazon EKS: используйте Amazon EKS для применения правил группы безопасности к модулям pod, которые выполняются в кластере. Используйте эту функцию для управления входящим и исходящим трафиком.

Дополнительные сведения см. в статье "Что такое Amazon EKS?".

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

Кластеры AKS требуют удостоверения Microsoft Entra для доступа к ресурсам Azure, таким как подсистемы балансировки нагрузки и управляемые диски. Рекомендуется использовать управляемые удостоверения для ресурсов Azure для авторизации доступа из кластера AKS к другим службам Azure.

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

Разработчики часто борются с управлением секретами, учетными данными, сертификатами и ключами, которые помогают защитить обмен данными между службами. Управляемые удостоверения устраняют необходимость управления этими учетными данными. Управляемые удостоверения можно использовать для проверки подлинности кластера AKS без управления учетными данными или их включения в код. Назначьте роль Azure RBAC объекту, чтобы предоставить данному объекту разрешения на доступ к определенным ресурсам в Azure.

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

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

  • Для идентичности создается специальный тип принципала службы в Microsoft Entra ID. Принципал службы привязан к жизненному циклу этого ресурса Azure. Когда ресурс Azure удаляется, Azure автоматически удаляет субъект-службу.

  • Только этот ресурс Azure может использовать удостоверение для запроса токенов из Microsoft Entra ID.

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

  • Имя назначаемого системой служебного аккаунта совпадает с именем ресурса Azure, для которого он создан.

• Назначаемое пользователем. Вы можете создать управляемое удостоверение в качестве автономного ресурса Azure. Вы можете создать управляемое удостоверение, назначаемое пользователем , и назначить его одному или нескольким ресурсам Azure. Когда вы включаете управляемую идентичность, назначаемую пользователем:

  • Для идентичности создается специальный тип принципала службы в Microsoft Entra ID. Субъект-служба управляется отдельно от ресурсов, которые его используют.

  • Им могут воспользоваться многочисленные ресурсы.

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

Для авторизации доступа к ресурсам Azure из кластера AKS можно использовать любой тип управляемого удостоверения.

Дополнительные сведения см. в разделе Типы управляемых удостоверений.

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

С кластером AKS можно использовать следующие типы управляемых удостоверений:

• Управляемое удостоверение, назначаемое системой, связано с одним ресурсом Azure, например кластером AKS. Он существует только для жизненного цикла кластера.

• Управляемое удостоверение, назначаемое пользователем , — это автономный ресурс Azure, который можно использовать для авторизации доступа к другим службам Azure из кластера AKS. Он сохраняется отдельно от кластера, и различные ресурсы Azure могут использовать его.

• Предварительно созданное управляемое удостоверение kubelet — это необязательное удостоверение, назначаемое пользователем, которое kubelet может использовать для доступа к другим ресурсам в Azure. Если управляемое удостоверение, назначаемое пользователем, не указано для kubelet, AKS создает удостоверение kubelet, назначаемое пользователем, в группе ресурсов узла.

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

При развертывании кластера AKS автоматически создается управляемое удостоверение, назначаемое системой. Вы также можете создать кластер с управляемым удостоверением, назначаемое пользователем. Кластер использует управляемую идентичность для запроса токенов из Microsoft Entra ID. Токены авторизуют доступ к другим ресурсам, которые запущены в Azure.

При назначении роли Azure RBAC управляемому удостоверению вы можете предоставить кластеру разрешения для доступа к конкретным ресурсам. Например, можно назначить управляемому удостоверению роль RBAC Azure, которая позволяет получить доступ к секретам в Azure Key Vault. Используйте этот подход, чтобы легко авторизовать доступ к кластеру без управления учетными данными.

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

При использовании управляемых удостоверений в AKS не требуется подготавливать или обновлять секреты. Azure управляет учетными данными идентичности. Таким образом, вы можете авторизовать доступ из приложений без управления дополнительными секретами.

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

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

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

Манажируемая идентичность	Вариант использования	Разрешения по умолчанию
Плоскость управления (назначенная системой)	Компоненты уровня управления AKS используют это удостоверение для управления ресурсами в кластере. К этим ресурсам относятся балансировщики нагрузки для входящего трафика, общедоступные IP-адреса AKS, автоматическое масштабирование кластеров, а также диски Azure и драйверы CSI для файлов и объектов BLOB.	Роль участника для группы ресурсов узла
Kubelet (назначаемый пользователем)	Проверка подлинности с помощью реестра контейнеров Azure.	N/A (для Kubernetes версии 1.15 и более поздних версий)
Удостоверения надстроек (AzureNPM, мониторинг сети AzureCNI, политика Azure и Calico)	Для этих надстроек не требуется удостоверение.	Не применимо
Маршрутизация приложений	Управляет сертификатами Azure DNS и Azure Key Vault.	Роль пользователя секретов для Key Vault, роль вкладчика зоны DNS для зон DNS, роль вкладчика частной зоны DNS для частных зон DNS
Шлюз приложений входящего трафика	Управляет необходимыми сетевыми ресурсами.	Роль участника для группы ресурсов узла
Агент набора средств управления операциями (OMS)	Отправляет метрики AKS в Azure Monitor.	Роль издателя метрик мониторинга
Виртуальный узел (соединитель экземпляров контейнеров Azure)	Управляет необходимыми сетевыми ресурсами для экземпляров контейнеров.	Роль участника для группы ресурсов узла
Анализ затрат	Собирает данные о выделении затрат.	Не применимо
Удостоверение рабочей нагрузки (идентификатор рабочей нагрузки)	Позволяет приложениям безопасно получать доступ к облачным ресурсам с помощью идентификатора рабочей нагрузки.	Не применимо

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

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

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

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

Чтобы полностью использовать идентификатор рабочей нагрузки в кластере Kubernetes, настройте кластер AKS для выдачи маркеров и публикации документа обнаружения OpenID Connect (OIDC) для проверки маркеров. Дополнительные сведения см. в статье "Создание поставщика OIDC в AKS".

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

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

Схема последовательности показывает взаимодействие между пятью компонентами: рабочей нагрузкой Kubelet, Kubernetes, идентификатором Microsoft Entra, документом обнаружения OpenID и ресурсами Azure. Взаимодействия нумеруются от 1 до 5. Стрелки указывают направление взаимодействия. Стрелка из Kubelet к рабочей нагрузке Kubernetes обозначена как 1. Стрелка от рабочей нагрузки Kubernetes к Microsoft Entra ID имеет обозначение "2". Стрелка от Microsoft Entra ID к документу обнаружения OpenID помечена как 3. Стрелка от Microsoft Entra ID обратно к нагрузке Kubernetes помечена как 4. Стрелка между рабочей нагрузкой Kubernetes и ресурсами Azure помечена числом 5.

1. kubelet Агент проецирует токен учетной записи службы для рабочей нагрузки по заданному пути к файлу.

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

3. Идентификатор Microsoft Entra использует документ обнаружения OIDC для проверки доверия в определяемом пользователем управляемом удостоверении или зарегистрированном приложении и проверке входящего маркера.

4. Идентификатор Microsoft Entra выдает токен доступа к безопасности.

5. Рабочая нагрузка Kubernetes обращается к ресурсам Azure с помощью маркера доступа Microsoft Entra.

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

• Проект с открытым исходным кодом идентификатора рабочей нагрузки
• федерация рабочих удостоверений
• Федерация идентификаторов рабочей нагрузки с Kubernetes
• Федерация идентификаторов рабочей нагрузки с внешними поставщиками удостоверений OIDC
• Минимальная федерация идентификации рабочей нагрузки
• Документация по идентификатору рабочей нагрузки
• Краткое руководство по идентификатору рабочей нагрузки
• Использование идентификатора рабочей нагрузки для Kubernetes с управляемым удостоверением, назначенным пользователем, в приложении .NET Standard

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

В следующем примере рабочая нагрузка выполняется в кластере AKS и состоит из интерфейсной и серверной службы. Эти службы используют идентификатор рабочей нагрузки для доступа к службам Azure, включая Key Vault, Azure Cosmos DB, учетные записи хранения Azure и пространства имен служебной шины Azure. Чтобы настроить эту примерную рабочую нагрузку, сделайте следующее:

1. Настройте кластер AKS с включенным поставщиком удостоверений OIDC и идентификацией рабочей нагрузки.

2. Создайте учетную запись службы Kubernetes в пространстве имен рабочей нагрузки.

3. Создайте управляемое удостоверение Microsoft Entra, назначенное пользователем, или зарегистрированное приложение.

4. Установите учетные данные федеративного удостоверения личности между управляемым удостоверением Microsoft Entra или зарегистрированным приложением и учетной записью службы обработки задания.

5. Назначьте необходимые роли с соответствующими разрешениями управляемому удостоверению Microsoft Entra или зарегистрированному приложению.

6. Разверните рабочую нагрузку и проверьте аутентификацию с помощью удостоверения рабочей нагрузки.

Поток сообщений идентификатора рабочей нагрузки

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

Основным разделом является настройка кластера AKS, которая включает контроллер входящего трафика NGINX и пространство имен Todolist и его компоненты. Контейнеры развертывания указывают шаг 1 в общем рабочем процессе. Поток 2 идёт от контейнеров развертывания к Microsoft Entra ID. Поток 3 идет от Microsoft Entra ID к URL-адресу издателя OIDC. Поток 4 передается из Microsoft Entra ID в контейнеры для развертывания. Поток 5 переходит из контейнеров развертывания в Azure Key Vault, служебную шину Azure, Azure Cosmos DB и учетную запись хранения Azure.

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

1. Kubernetes выдает токен модулю, когда модуль планируется на узле. Этот токен основан на спецификациях «pod» или «deployment».

2. Модуль pod отправляет токен, выданный OIDC, в Microsoft Entra ID, чтобы запросить токен Microsoft Entra для конкретного appId и ресурса.

3. Идентификатор Microsoft Entra подтверждает доверие приложения и проверяет входящие токены.

4. Идентификатор Microsoft Entra выдает маркер безопасности: {sub: appId, aud: requested-audience}

5. Pod использует токен Microsoft Entra для доступа к целевому ресурсу Azure.

Чтобы использовать идентификатор рабочей нагрузки в кластере Kubernetes, следуйте этим шагам.

1. Настройте кластер AKS для выдачи маркеров и публикации документа обнаружения OIDC, чтобы разрешить проверку этих маркеров.

2. Настройте приложения Microsoft Entra для принятия токенов Kubernetes.

3. Разработчики настраивают свои развертывания для использования учетных записей Kubernetes для получения токенов Kubernetes.

4. Идентификатор рабочей нагрузки производит обмен токенов Kubernetes на токены Microsoft Entra.

5. Рабочие нагрузки кластера AKS используют маркеры Microsoft Entra для доступа к защищенным ресурсам, таким как Microsoft Graph.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

• Паоло Сальватори | Инженер основной службы
• Мартин Gjoшевски | Старший инженер службы

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

• Лора Николас | Старший инженер по программному обеспечению
• Чад Киттель | Главный инженер по программному обеспечению — шаблоны и методики Azure
• Эд Прайс | Старший диспетчер программ содержимого
• Теано Питерсен | Технический писатель

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

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

• Использование учетной записи службы с AKS
• Использование управляемой идентичности в AKS
• Путь обучения: управление удостоверениями и доступом в Microsoft Entra ID

Связанные ресурсы

• AKS для специалистов Amazon EKS
• Мониторинг и ведение журнала Kubernetes
• Безопасный сетевой доступ к Kubernetes
• Параметры хранилища для кластера Kubernetes
• Управление затратами для Kubernetes
• Управление узлами и пулом узлов Kubernetes
• Управление кластерами
• Управление удостоверениями и управление доступом Microsoft Entra для AWS