#c# #azure #azure-active-directory #azure-aks
#c# #azure #azure-active-directory #azure-aks
Вопрос:
является ли это способом получения идентификатора объекта и идентификатора приложения службы Azure Kubernetes
Примечание * участника службы службы kubernetes нет в Active Directory, он был создан только с помощью AKS, и его роль Acrpull назначена реестрам контейнеров ACR
Комментарии:
1. Когда вы сказали «.. участник службы службы kubernetes не находится в Active Directory, он был создан только с помощью AKS», вы имеете в виду интеграцию Azure Active Directory под управлением AKS ?
2. Или это управляемые идентификаторы в службе Azure Kubernetes ?
3. @KrishnenduGhosh-MSFT ни один aks не является управляемым AD или это не управляемые идентификаторы
4. Тогда не могли бы вы уточнить утверждение?
Ответ №1:
Я думаю, у вас неправильное понимание участника службы службы Azure Kubernetes.
Участник службы — это точно управляемый идентификатор службы Azure Kubernetes.
Когда вы создаете кластер службы Azure Kubernetes (AKS), вам необходимо настроить для него метод аутентификации. Здесь я выбираю «Назначенное системой управляемое удостоверение».
После этого вы можете найти его в Azure AD -> Корпоративные приложения -> Все приложения (просто найдите имя кластера служб Azure Kubernetes (AKS)). Но это недоступно в Azure AD -> Регистрации приложений.
Другой быстрый способ — использовать Azure CLI. Ссылка здесь.
Создайте кластер AKS:
az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity
А затем используйте следующую команду для запроса идентификатора объекта вашего управляемого идентификатора плоскости управления:
az aks show -g myResourceGroup -n myManagedCluster --query "identity"
Кроме того, если вы попытаетесь назначить роль реестрам контейнеров ACR с этим участником службы на портале Azure, вводить идентификатор объекта необязательно. Достаточно ввести имя кластера AKS.