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
5 comments
-
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.