Использование Идентификация рабочей нагрузки Microsoft Entra с Служба Azure Kubernetes (AKS)
Рабочие нагрузки, развернутые в кластере Служба Azure Kubernetes (AKS), требуют учетных данных приложения Microsoft Entra или управляемых удостоверений для доступа к защищенным ресурсам Microsoft Entra, таким как Azure Key Vault и Microsoft Graph. Идентификация рабочей нагрузки Microsoft Entra интегрируется с возможностями, собственными для Kubernetes, для федерации с внешними поставщиками удостоверений.
Идентификация рабочей нагрузки Microsoft Entra использует проекцию тома маркера учетной записи службы (т. е. учетную запись службы), чтобы модули pod могли использовать удостоверение Kubernetes. Токен Kubernetes выдан, а федерация OIDC позволяет приложениям Kubernetes безопасно получать доступ к ресурсам Azure с помощью идентификатора Microsoft Entra, основанного на учетных записях службы с аннотированием.
Идентификация рабочей нагрузки Microsoft Entra работает особенно хорошо с Клиентские библиотеки удостоверений Azure или коллекция библиотеки проверки подлинности Майкрософт (MSAL) вместе с регистрацией приложения. Рабочая нагрузка может использовать любую из этих библиотек, чтобы легко пройти проверку подлинности и получить доступ к облачным ресурсам Azure.
Эта статья поможет вам понять Идентификация рабочей нагрузки Microsoft Entra и просмотреть варианты, доступные для планирования стратегии проекта и потенциальной миграции с управляемого удостоверений Microsoft Entra pod.
Примечание.
Соединитель служб можно использовать для автоматической настройки некоторых шагов. См. также: Что такое соединитель служб?
Зависимости
- AKS поддерживает Идентификация рабочей нагрузки Microsoft Entra версии 1.22 и выше.
- Azure CLI версии 2.47.0 или более поздней. Запустите
az --version
, чтобы определить версию и запуститеaz upgrade
для обновления версии. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
Клиентские библиотеки удостоверений Azure
В клиентских библиотеках удостоверений Azure выберите один из следующих подходов:
- Используется
DefaultAzureCredential
, который пытается использоватьWorkloadIdentityCredential
. - Создание экземпляра
ChainedTokenCredential
, который включает в себяWorkloadIdentityCredential
. - Используйте
WorkloadIdentityCredential
напрямую.
В следующей таблице приведена минимальная версия пакета, необходимая для каждой клиентской библиотеки экосистемы языков.
Экосистема | Библиотека | Минимальная версия |
---|---|---|
.NET | Azure.Identity | 1.9.0 |
C++ | azure-identity-cpp | 1.6.0 |
Go | azidentity | 1.3.0 |
Java | azure-identity | 1.9.0 |
Node.js | @azure/identity | 3.2.0 |
Python | azure-identity | 1.13.0 |
В следующих примерах DefaultAzureCredential
кода используется. Этот тип учетных данных использует переменные среды, введенные удостоверением рабочей нагрузки Azure, для проверки подлинности в Azure Key Vault.
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");
var client = new SecretClient(
new Uri(keyVaultUrl),
new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync(secretName);
Библиотека проверки подлинности Майкрософт (MSAL)
Следующие клиентские библиотеки являются минимальной версией.
Экосистема | Библиотека | Изображения | Пример | Имеет Windows |
---|---|---|---|---|
.NET | Библиотека проверки подлинности Майкрософт для dotnet | ghcr.io/azure/azure-workload-identity/msal-net:latest |
Ссылка | Да |
Go | Библиотека проверки подлинности Майкрософт для использования | ghcr.io/azure/azure-workload-identity/msal-go:latest |
Ссылка | Да |
Java | Библиотека проверки подлинности Майкрософт для java | ghcr.io/azure/azure-workload-identity/msal-java:latest |
Ссылка | No |
JavaScript | Библиотека проверки подлинности Майкрософт для js | ghcr.io/azure/azure-workload-identity/msal-node:latest |
Ссылка | No |
Python | Библиотека проверки подлинности Майкрософт для Python | ghcr.io/azure/azure-workload-identity/msal-python:latest |
Ссылка | No |
Ограничения
- Для каждого управляемого удостоверения можно иметь не более 20 федеративных учетных данных.
- Для распространения учетных данных федеративного удостоверения после первоначального добавления потребуется несколько секунд.
- Виртуальные узлы, добавленные на основе проекта открытый код Virtual Kubelet, не поддерживаются.
- Создание учетных данных федеративного удостоверения не поддерживается для управляемых удостоверений, назначаемых пользователем, в этих регионах.
Принцип работы
В этой модели безопасности кластер AKS выступает в качестве издателя маркеров. Идентификатор Microsoft Entra использует OpenID Connect для обнаружения открытых ключей подписывания и проверки подлинности маркера учетной записи службы перед обменом на токен Microsoft Entra. Рабочая нагрузка может обмениваться маркером учетной записи службы, проецируемым на его том, для маркера Microsoft Entra с помощью клиентской библиотеки удостоверений Azure или библиотеки проверки подлинности Майкрософт (MSAL).
В следующей таблице описаны необходимые конечные точки издателя OIDC для Идентификация рабочей нагрузки Microsoft Entra:
Конечная точка | Description |
---|---|
{IssuerURL}/.well-known/openid-configuration |
Также известен как документ обнаружения OIDC. Это содержит метаданные о конфигурациях издателя. |
{IssuerURL}/openid/v1/jwks |
Это содержит открытые ключи подписывания, которые использует идентификатор Microsoft Entra для проверки подлинности маркера учетной записи службы. |
На следующей схеме показана последовательность проверки подлинности с помощью OpenID Connect.
Автоматическая смена сертификата веб-перехватчика
Аналогично другим надстройкам веб-перехватчика, сертификат поворачивается операцией автоматической смены сертификата кластера.
Метки и заметки учетной записи службы
Идентификация рабочей нагрузки Microsoft Entra поддерживает следующие сопоставления, связанные с учетной записью службы:
- Один к одному, где учетная запись службы ссылается на объект Microsoft Entra.
- Многие к одному, где несколько учетных записей служб ссылались на один и тот же объект Microsoft Entra.
- Один ко многим, где учетная запись службы ссылается на несколько объектов Microsoft Entra путем изменения заметки идентификатора клиента. Дополнительные сведения см. в статье "Как настроить федерацию нескольких удостоверений с учетной записью службы Kubernetes".
Примечание.
Если заметки учетной записи службы обновляются, необходимо перезапустить pod, чтобы изменения вступили в силу.
Если вы использовали управляемое пользователем удостоверение Microsoft Entra pod, то думайте о учетной записи службы как субъекте безопасности Azure, за исключением того, что учетная запись службы является частью основного API Kubernetes, а не пользовательского определения ресурсов (CRD). В следующих разделах описан список доступных меток и заметок, которые можно использовать для настройки поведения при обмене маркером учетной записи службы для маркера доступа Microsoft Entra.
Заметки учетной записи службы
Все заметки являются необязательными. Если заметка не указана, будет использоваться значение по умолчанию.
Номер | Description | По умолч. |
---|---|---|
azure.workload.identity/client-id |
Представляет приложение Microsoft Entra Идентификатор клиента, используемый с модулем pod. |
|
azure.workload.identity/tenant-id |
Представляет идентификатор клиента Azure, в котором Приложение Microsoft Entra зарегистрировано. |
извлеченная переменная среды AZURE_TENANT_ID из azure-wi-webhook-config ConfigMap. |
azure.workload.identity/service-account-token-expiration |
expirationSeconds Представляет поле для поляпроецируемый маркер учетной записи службы. Это необязательное поле, которое вы настраиваете для предотвращения простоя вызваны ошибками при обновлении маркера учетной записи службы. Срок действия маркера учетной записи службы Kubernetes не связан с токенами Microsoft Entra. Срок действия маркеров Microsoft Entra истекает через 24 часа после их выдачи. |
3600 Поддерживаемый диапазон — 3600–86400. |
Метки pod
Примечание.
Для приложений, использующих удостоверение рабочей нагрузки, необходимо добавить метку azure.workload.identity/use: "true"
в спецификацию pod для AKS для перемещения удостоверения рабочей нагрузки в сценарий fail Close , чтобы обеспечить согласованное и надежное поведение модулей pod, которые должны использовать удостоверение рабочей нагрузки. В противном случае модули pod завершаются сбоем после перезапуска.
Label | Description | Рекомендуемое значение | Обязательное поле |
---|---|---|---|
azure.workload.identity/use |
Эта метка требуется в спецификации шаблона pod. Только модули pod с этой меткой мутируются с помощью удостоверений azure-workload-mutating webhook для внедрения переменных среды Azure и проецируемого тома маркера учетной записи службы. | true | Да |
Заметки pod
Все заметки являются необязательными. Если заметка не указана, будет использоваться значение по умолчанию.
Номер | Description | По умолч. |
---|---|---|
azure.workload.identity/service-account-token-expiration |
expirationSeconds Представляет поле для проецируемого маркера учетной записи службы. Это необязательное поле, которое настраивается для предотвращения простоя, вызванного ошибками при обновлении маркера учетной записи службы. Срок действия маркера учетной записи службы Kubernetes не связан с токенами Microsoft Entra. Срок действия маркеров Microsoft Entra истекает через 24 часа после их выдачи. 1 |
3600 Поддерживаемый диапазон — 3600–86400. |
azure.workload.identity/skip-containers |
Представляет разделенный точкой с запятой список контейнеров для пропуска добавления проецируемого тома маркера учетной записи службы. Например, container1;container2 . |
По умолчанию том маркера проецируемого маркера учетной записи службы добавляется ко всем контейнерам, если модуль pod помечен с azure.workload.identity/use: true меткой. |
azure.workload.identity/inject-proxy-sidecar |
Внедряет контейнер инициализацию прокси-сервера и боковую панель прокси-сервера в модуль pod. Прокси-сервер используется для перехвата запросов маркеров в IMDS и получения маркера Microsoft Entra от имени пользователя с федеративными учетными данными удостоверения. | true |
azure.workload.identity/proxy-sidecar-port |
Представляет порт прокси-сервера. | 8000 |
1 Имеет приоритет, если учетная запись службы также заметен.
Переход на Идентификация рабочей нагрузки Microsoft Entra
В кластере, который уже работает с управляемым модулем pod, его можно настроить для использования удостоверения рабочей нагрузки одним из двух способов. Первый вариант позволяет использовать ту же конфигурацию, которую вы реализовали для управляемого pod удостоверения. Учетную запись службы в пространстве имен можно идентифицировать, чтобы включить Идентификация рабочей нагрузки Microsoft Entra и внедрить заметки в модули pod.
Второй вариант — перезаписать приложение, чтобы использовать последнюю версию клиентской библиотеки удостоверений Azure.
Чтобы упростить процесс миграции и упростить процесс миграции, мы разработали боковик миграции, который преобразует транзакции IMDS, выполняемые приложением, в OpenID Connect (OIDC). Боковой автомобиль миграции не предназначен для долгосрочного решения, но способ быстрого выполнения и быстрого выполнения на удостоверениях рабочей нагрузки. Запуск бокового автомобиля миграции в прокси приложения выполняет транзакции IMDS приложения к OIDC. Альтернативный подход — обновление до поддерживаемой версии клиентской библиотеки удостоверений Azure, которая поддерживает проверку подлинности OIDC.
В следующей таблице приведены рекомендации по миграции или развертыванию для удостоверения рабочей нагрузки.
Сценарий | Description |
---|---|
Новое или существующее развертывание кластера запускает поддерживаемую версию клиентской библиотеки удостоверений Azure | Никаких шагов миграции не требуется. Пример ресурсов развертывания: развертывание и настройка удостоверения рабочей нагрузки в новом кластере |
Новое или существующее развертывание кластера выполняет неподдерживаемую версию клиентской библиотеки удостоверений Azure. | Обновите образ контейнера, чтобы использовать поддерживаемую версию пакета SDK для удостоверений Azure или использовать боковику миграции. |
Следующие шаги
- Чтобы узнать, как настроить модуль pod для проверки подлинности с помощью удостоверения рабочей нагрузки в качестве параметра миграции, см . статью "Модернизация проверки подлинности приложения с помощью удостоверения рабочей нагрузки".
- См. раздел "Развертывание и настройка кластера AKS с удостоверением рабочей нагрузки", который помогает развернуть кластер Служба Azure Kubernetes и настроить пример приложения для использования удостоверения рабочей нагрузки.
Azure Kubernetes Service