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
martin francis commented
Yes pls. Non interactive login is very important for CI/CD tools, IDE tools etc . putting my vote in
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
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)
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.
I was looking for similar functionality with MSI integration.