Интеграция идентификатора Microsoft Entra с Служба Azure Kubernetes (AKS) с помощью Azure CLI (устаревшая версия)
Предупреждение
Функция, описанная в этом документе, microsoft Entra Integration (устаревшая версия) была устарела 1 июня 2023 года. В настоящее время новые кластеры не могут быть созданы с помощью интеграции Microsoft Entra (устаревшая версия).
AKS имеет новый улучшенный интерфейс, управляемый Microsoft Entra ID , который не требует управления сервером или клиентскими приложениями. Если вы хотите перейти на новую версию, следуйте инструкциям здесь.
Служба Azure Kubernetes (AKS) можно настроить для использования идентификатора Microsoft Entra для проверки подлинности пользователей. В этой конфигурации можно войти в кластер AKS с помощью маркера проверки подлинности Microsoft Entra. Операторы кластера могут также настроить управление доступом на основе ролей (RBAC) для Kubernetes в зависимости от членства в группе каталогов или удостоверения пользователей.
В этой статье показано, как создать необходимые компоненты Microsoft Entra, а затем развернуть кластер с поддержкой идентификатора Microsoft и создать базовую роль Kubernetes в кластере AKS.
Ограничения
- Идентификатор Microsoft Entra можно включить только в кластере с поддержкой Kubernetes RBAC.
- Устаревшая интеграция Microsoft Entra может быть включена только во время создания кластера.
Подготовка к работе
Необходимо установить и настроить Azure CLI версии 2.0.61 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
Перейдите по адресу https://shell.azure.com, чтобы открыть Cloud Shell в браузере.
Для обеспечения согласованности и для выполнения команд в этой статье создайте переменную для нужного имени кластера AKS. В следующем примере используется имя myakscluster:
aksname="myakscluster"
Обзор проверки подлинности Microsoft Entra
Проверка подлинности Microsoft Entra предоставляется кластерам AKS с Подключение OpenID. OpenID Connect представляет собой уровень идентификации на основе протокола OAuth 2.0. Дополнительные сведения о OpenID Подключение см. в документации по OpenID Подключение.
Внутри кластера Kubernetes проверка подлинности на основе маркера веб-перехватчика используется для проверки маркеров проверки подлинности. Настройка такой проверка подлинности и ее управление являются частью кластера AKS. Дополнительные сведения о проверке подлинности на основе маркера веб-перехватчика см. в Документации по аутентификации веб-перехватчика.
Примечание.
При настройке идентификатора Microsoft Entra для проверки подлинности AKS настраиваются два приложения Microsoft Entra. Эту операцию должен выполнять администратор клиента Azure.
Создание компонента сервера Microsoft Entra
Чтобы интегрироваться с AKS, вы создаете и используете приложение Microsoft Entra, которое выступает в качестве конечной точки для запросов удостоверений. Первое приложение Microsoft Entra, которое требуется, получает членство в группе Microsoft Entra для пользователя.
Создайте компонент серверного приложения с помощью команды az ad app create, а затем обновите утверждения членства в группе с помощью команды az ad app update. В следующем примере используется переменная aksname, определенная в разделе Перед началом, и создается переменная.
# Create the Azure AD application
serverApplicationId=$(az ad app create \
--display-name "${aksname}Server" \
--identifier-uris "https://${aksname}Server" \
--query appId -o tsv)
# Update the application group membership claims
az ad app update --id $serverApplicationId --set groupMembershipClaims=All
Теперь создайте субъект-службу для серверного приложения с помощью команды az ad sp create. Этот субъект-служба используется для аутентификации на платформе Azure. Затем получите секрет субъекта-службы с помощью команды az ad sp credential reset и назначьте его переменной с именем serverApplicationSecret для использования в одном из следующих шагов:
# Create a service principal for the Azure AD application
az ad sp create --id $serverApplicationId
# Get the service principal secret
serverApplicationSecret=$(az ad sp credential reset \
--name $serverApplicationId \
--credential-description "AKSPassword" \
--query password -o tsv)
Субъект-служба Microsoft Entra нуждается в разрешениях для выполнения следующих действий:
- Прочитать данные каталога
- Вход в систему и чтение профиля пользователя
Назначьте эти разрешения с помощью команды az ad app permission add:
az ad app permission add \
--id $serverApplicationId \
--api 00000003-0000-0000-c000-000000000000 \
--api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope 06da0dbc-49e2-44d2-8312-53f166ab848a=Scope 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role
Наконец, предоставьте разрешения, назначенные на предыдущем шаге для серверного приложения, с помощью команды az ad app permission grant. Этот шаг завершается ошибкой, если текущая учетная запись не является администратором клиента. Кроме того, необходимо добавить разрешения для приложения Microsoft Entra, чтобы запросить сведения, которые могут потребовать согласия администратора администратора приложения az ad:
az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000
az ad app permission admin-consent --id $serverApplicationId
Создание клиентского компонента Microsoft Entra
Второе приложение Microsoft Entra используется при входе пользователя в кластер AKS с помощью интерфейса командной строки Kubernetes (kubectl). Это клиентское приложение принимает запрос на аутентификацию от пользователя и проверяет его учетные данные и разрешения. Создайте приложение Microsoft Entra для клиентского компонента с помощью команды az ad app create :
clientApplicationId=$(az ad app create \
--display-name "${aksname}Client" \
--native-app \
--reply-urls "https://${aksname}Client" \
--query appId -o tsv)
Создайте субъект-службу для клиентского приложения с помощью команды az ad sp create:
az ad sp create --id $clientApplicationId
С помощью команды az ad app show получите идентификатор oAuth2 для серверного приложения, чтобы можно было использовать поток аутентификации между двумя компонентами приложения. Этот идентификатор oAuth2 используется на следующем шаге.
oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)
Добавьте разрешения для клиентского и серверного приложения, чтобы использовать поток обмена данными oAuth2, с помощью команды az add app permission add. С помощью команды az ad app permission grant предоставьте разрешения на обмен данными между клиентским приложением и серверным приложением:
az ad app permission add --id $clientApplicationId --api $serverApplicationId --api-permissions ${oAuthPermissionId}=Scope
az ad app permission grant --id $clientApplicationId --api $serverApplicationId
Развертывание кластера
После создания двух приложений Microsoft Entra теперь создайте сам кластер AKS. Сначала создайте группу ресурсов с помощью команды az group create. В следующем примере создается группа ресурсов в регионе EastUS (Восточная часть США):
Создайте группу ресурсов для кластера:
az group create --name myResourceGroup --location EastUS
Получите идентификатор арендатора подписки Azure с помощью команды az account show. Теперь создайте кластер AKS, выполнив команду az aks create. Команда для создания кластера AKS предоставляет идентификаторы серверного и клиентского приложений, секрет субъекта-службы серверного приложения и идентификатор арендатора:
tenantId=$(az account show --query tenantId -o tsv)
az aks create \
--resource-group myResourceGroup \
--name $aksname \
--node-count 1 \
--generate-ssh-keys \
--aad-server-app-id $serverApplicationId \
--aad-server-app-secret $serverApplicationSecret \
--aad-client-app-id $clientApplicationId \
--aad-tenant-id $tenantId
Наконец, получите учетные данные администратора для кластера с помощью команды az aks get-credentials. На одном из следующих шагов вы получите учетные данные для обычного кластера пользователей , чтобы увидеть поток проверки подлинности Microsoft Entra в действии.
az aks get-credentials --resource-group myResourceGroup --name $aksname --admin
Создание привязки RBAC Kubernetes
Перед использованием учетной записи Microsoft Entra с кластером AKS необходимо создать привязку ролей или привязку роли кластера. Роли определяют разрешения для предоставления, а привязки применяют их к желаемым пользователям. Эти назначения могут применяться для определенного пространства имен или в масштабах всего кластера. Дополнительные сведения см. в разделе Использование авторизации RBAC Kubernetes.
Получите имя участника-пользователя (UPN) для вошедшего в систему пользователя с помощью команды az ad signed-in-user show. Эта учетная запись пользователя включена для интеграции Microsoft Entra на следующем шаге.
az ad signed-in-user show --query userPrincipalName -o tsv
Внимание
Если пользователь, которому предоставлена привязка Kubernetes RBAC, находится в том же клиенте Microsoft Entra, назначьте разрешения на основе userPrincipalName. Если пользователь находится в другом клиенте Microsoft Entra, выполните запрос и используйте свойство objectId .
Создайте манифест YAML с именем basic-azure-ad-binding.yaml и вставьте в него приведенное ниже содержимое. В последней строке замените userPrincipalName_or_objectId на выходные данные имени участника-пользователя или идентификатора объекта из предыдущей команды:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: contoso-cluster-admins
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: userPrincipalName_or_objectId
Создайте ClusterRoleBinding с помощью команды kubectl apply и укажите имя файла манифеста YAML:
kubectl apply -f basic-azure-ad-binding.yaml
Доступ к кластеру с идентификатором Microsoft Entra
Теперь давайте протестируем интеграцию проверки подлинности Microsoft Entra для кластера AKS. Настройте контекст конфигурации kubectl, чтобы использовать учетные данные стандартного пользователя. Этот контекст передает все запросы проверки подлинности через идентификатор Microsoft Entra.
az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing
Воспользуйтесь командой kubectl get pods для просмотра всех объектов pod во всех пространствах имен:
kubectl get pods --all-namespaces
Вы получите запрос на вход для проверки подлинности с помощью учетных данных Microsoft Entra с помощью веб-браузера. После успешной аутентификации команда kubectl отображает объекты pod в кластере AKS, как показано в следующем примере выходных данных:
kubectl get pods --all-namespaces
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BYMK7UXVD to authenticate.
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-754f947b4-2v75r 1/1 Running 0 23h
kube-system coredns-754f947b4-tghwh 1/1 Running 0 23h
kube-system coredns-autoscaler-6fcdb7d64-4wkvp 1/1 Running 0 23h
kube-system heapster-5fb7488d97-t5wzk 2/2 Running 0 23h
kube-system kube-proxy-2nd5m 1/1 Running 0 23h
kube-system kube-svc-redirect-swp9r 2/2 Running 0 23h
kube-system kubernetes-dashboard-847bb4ddc6-trt7m 1/1 Running 0 23h
kube-system metrics-server-7b97f9cd9-btxzz 1/1 Running 0 23h
kube-system tunnelfront-6ff887cffb-xkfmq 1/1 Running 0 23h
Маркер проверки подлинности, полученный для kubectl, кэшируется. Повторный запрос на вход появится только в случае истечения срока действия маркера или повторного создания файла конфигурации Kubernetes.
Если вы видите сообщение об ошибке авторизации после успешного входа с помощью веб-браузера, как показано в примере выходных данных ниже, проверьте следующее:
error: You must be logged in to the server (Unauthorized)
- Вы определили соответствующий идентификатор объекта или имя участника-пользователя в зависимости от того, находится ли учетная запись пользователя в том же клиенте Microsoft Entra или нет.
- Пользователь не может быть членом более чем 200 групп.
- Секрет, определенный в регистрации приложения для сервера, соответствует значению, заданному с помощью
--aad-server-app-secret. - Убедитесь, что на компьютере установлена только одна версия kubectl. Конфликтующие версии могут вызвать проблемы во время авторизации. Чтобы установить последнюю версию, выполните команду az aks install-cli.
Часто задаваемые вопросы о миграции с Microsoft Entra Integration на идентификатор Microsoft Entra, управляемый AKS
1. Что такое план миграции?
Интеграция Microsoft Entra (устаревшая версия) будет устарела 1 июня 2023 года. После этой даты вы не сможете создавать новые кластеры с идентификатором Microsoft Entra (устаревшая версия). Мы переносим все кластеры AKS, управляемые Microsoft Entra Integration (устаревшая версия), в идентификатор Microsoft Entra, управляемый AKS, автоматически начиная с 1 августа 2023 года. Мы отправим уведомления по электронной почте администраторам подписки, затронутым двуадминистраторами, чтобы напомнить им о миграции.
2. Что произойдет, если я не принимаю никаких действий?
Кластеры AKS microsoft Entra Integration (устаревшая версия) будут продолжать работать после 1 июня 2023 года. Мы автоматически переносим кластеры в идентификатор Microsoft Entra, управляемый AKS, начиная с 1 августа 2023 г. Во время миграции может возникнуть простой сервера API.
Содержимое kubeconfig изменяется после миграции. Необходимо объединить новые учетные данные в файл kubeconfig с помощью файла az aks get-credentials --resource-group <AKS resource group name> --name <AKS cluster name>.
Рекомендуется вручную обновить кластер AKS до идентификатора Microsoft Entra, управляемого AKS, до 1 августа. Таким образом, вы можете управлять временем простоя в нерабочие часы, когда это удобнее.
3. Почему после миграции вручную по-прежнему отображается сообщение электронной почты с уведомлением?
Для отправки сообщения электронной почты требуется несколько дней. Если кластер не был перенесен до запуска процесса отправки электронной почты, вы все равно получите уведомление.
4. Как проверка ли мой кластер перенесен в идентификатор Записи Майкрософт, управляемый AKS?
Убедитесь, что кластер AKS переносится в идентификатор Microsoft Entra, управляемый AKS, с помощью az aks show команды.
az aks show -g <RGName> -n <ClusterName> --query "aadProfile"
Если кластер использует идентификатор Microsoft Entra, управляемый AKS, отображается managedtrueрезультат. Например:
{
"adminGroupObjectIDs": [
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
],
"adminUsers": null,
"clientAppId": null,
"enableAzureRbac": null,
"managed": true,
"serverAppId": null,
"serverAppSecret": null,
"tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
Следующие шаги
Полный скрипт, содержащий команды, показанные в этой статье, см. в [скрипте интеграции Microsoft Entra в репозитории примеров AKS][complete-script].
Сведения об использовании пользователей и групп Microsoft Entra для управления доступом к ресурсам кластера см. в статье "Управление доступом к ресурсам кластера с помощью управления доступом на основе ролей Kubernetes" и удостоверений Microsoft Entra в AKS.
Дополнительные сведения о защите кластеров Kubernetes см. в разделе параметры доступа и удостоверений для AKS).
Рекомендации по управлению удостоверениями и ресурсами см. в статье Рекомендации по аутентификации и авторизации в службе Azure Kubernetes (AKS).