Support non-interactive login for AAD-integrated clusters
Currently if your cluster is integrated with AAD, any kubectl command will prompt you for an interactive login, even after logging in via Azure CLI and obtaining Kubectl credentials using 'az aks get-credentials'.
This won't work for anything using automation (e.g. a CI server such as Jenkins).
Ideally one could log in using a service principal who is then mapped to roles using RBAC. Once you are logged in via the Azure CLI, you could obtain the credentials and execute Kubectl commands as normal.
Original issue here: https://github.com/Azure/AKS/issues/556
A similar issue was raised here, but I would like to be able to do this without having to distribute credentials: https://github.com/Azure/AKS/issues/600
Tim Webster
shared this idea
11 comments
-
Siva
commented
I vote for this feature. Much needed for my CI/CD automation
-
Anonymous
commented
Putting my vote in
-
Anonymous
commented
+1
-
Andreas
commented
I ended up here via some detours because of a question I raised here: https://github.com/kubernetes-client/csharp/issues/354
Support via the .NET Azure SDK trough this code snippet for AAD integrated AKS clusters is needed:
var client = Azure
.Configure()
.Authenticate(credentials)
.WithSubscription(subscription);
var kubeConfigFileContent = client.KubernetesClusters
.GetUserKubeConfigContentsAsync(resourceGroup, clusterName).Result;The kubeConfigFileContent generated does not contain an access token, preventing it to connect trough the azure auth provider for using the k8s .NET sdk (which does support it if the access token would be there).
This prevents us from using managed service principles to connect from a .NET headless service to a k8s cluster. Using native k8s service principles instead of integrated AAD ones defeats the purpose, as well as asking for the admin kubeConfig. -
martin francis
commented
Yes pls. Non interactive login is very important for CI/CD tools, IDE tools etc . putting my vote in
-
Anonymous
commented
Please managing two sets of authentications (on Kubernetes as service accounts an on Azure AD), is at most a hack, not a long term solution. Could we please just have some kind of non-interactive RBAC login.
-
Alessandro Vozza
commented
Having AAD enabled doesn't preclude from create a service account in Kubernetes with a specific role and rolebinding, and using the relative kubeconfig to pass to Jenkins to use that service account to perform action in kubernetes
-
Rene
commented
In lint with the comment of Nick Muller, our release now looks as follows:
1. Azure CLI task with az aks get-credentials -g <AKS-RG> -n <AKS_CLUSTER> --admin
2. Kubectl task with:
- serviceconnection set to none
- Under Advanced: Specify kubectl location, point the path to $(System.DefaultWorkingDirectory) (assuming the az cli command was also performed in the default working directory) -
Anonymous
commented
-
Nick Muller
commented
As a workaround the automation tools can obtain cluster admin credentials via `az aks get-credentials --admin`.
Not best practice, but at least this way CI/CD can be implemented. -
Ron
commented
I was looking for similar functionality with MSI integration.