Мне нужно предоставить процессу (конвейеру сборки) доступ RBAC к AKS API для целей развертывания. Но в целевом кластере AKS активна интеграция с AAD (как описано здесь )
Я ожидал получить доступ к AKS API с помощью простого субъекта-службы, но меня перенаправили на страницу входа в устройство:
$ az login --service-principal --username [REDACTED]-XXXX-XXXX-XXXX-XXXXXXXXXXXX --password [REDACTED]XXxxXXxxXXxxxXXXxxXXxxXXxx= --tenant [REDACTED]-XXXX-XXXX-XXXX-XXXXXXXXXXXX
$ az aks get-credentials -n oli-aksdemo01 -g oli-aksdemo01
Merged "oli-aksdemo01" as current context in /home/olivier/.kube/config
$ kubectl get nodes
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code C2NP77EGR to authenticate.
: - (
Есть ли способ избежать страницы входа в устройство при аутентификации субъекта-службы в кластере AKS, интегрированном с AAD, в Azure?
TL; DR: Пока это невозможно.
Я задал тот же вопрос службе поддержки Azure, и вот их ответ:
Когда кластер AKS интегрирован с AAD, он потребуется перенаправление на страницу входа в систему при аутентификации для доступа к кластеру.
Доступ к кластеру с помощью Azure AD - https://docs.microsoft.com/en-us/azure/aks/aad-integration#access-cluster-with-azure-ad
К сожалению, в настоящее время это сделано намеренно, и другого способа пока избегайте этого процесса, но мы хотели бы услышать ваш голос.
Не могли бы вы оставить свой отзыв по ссылкам ниже, чтобы мы могут планировать в будущем.
https://feedback.azure.com/forums/914020-azure-kubernetes-service-aks
Для всех, кому это все еще нужно.
Я решил ту же проблему для конвейера Jenkins. Все, что вам нужно сделать, это создать субъект-службу с областью или подпиской кластера.
#login
az login --service-principal --username <app-key> --password <password> --tenant <tenant>
# Get the admin credentials for the kubeconfig context
az aks get-credentials --resource-group $resourcegroup --name $aksname --admin
#
kubectl get pods
Все должно быть в порядке.
В отличие от ответа @Festus Fashola, который работает просто потому, что он использует флаг --admin
в команде, которая обходит проверку AAD (а не то, что спрашивал ОП), правильный способ сделать это сейчас с помощью KubeLogin, который обеспечивает неинтерактивную аутентификацию субъекта-службы: https://github.com/Azure/kubelogin#service-principal-login-flow-non-interactive