If you have ever installed Kubernetes on your own hardware or you have worked with Kubernetes on the desktop with a tool like kind, you probably know that you need a config file that tells the Kubernetes CLI (kubectl) how to talk to the Kubernetes API server. It contains the address of the API server, the cert of the CA that issued the API Server’s SSL certificate and more. Check the docs for more information. Tools like kind make it very easy because they create the file automatically or merge connection information into an existing config file.
For example, when you run kind create cluster, you will see the following message at the end:
The message Set kubectl context to kind-kind indicates that the config file in $HOME/.kube was modified. If you were to check the config file, you would find a client certificate and client key to authenticate to kind. Client certificate authentication is a very common way to authenticate to Kubernetes.
Azure AD authentication
In an enterprise context, you should not rely on client certificate authentication. It would be too cumbersome to create and manage all these client certificates. The level of control over these certificates is limited as well. In a Microsoft context with users, groups and service principals (think service accounts) in Azure Active Directory, Kubernetes should be integrated with that. If you are using Azure-managed Kubernetes with AKS, that is very easy to do with AKS-managed AAD authentication. There is also a manual method of integrating with AAD but you should not use that anymore. There is still some time to move away from that method though. 😀
To illustrate how you logon with Azure AD and how to bypass AAD, I created a video on my YouTube channel:
Azure AD Authentication in a pipeline
If you watched the video, you know you need to interactively provide your credentials when you perform an action that needs to be authenticated. After providing your credentials, kubectl has an access token (JWT) to pass to the Kubernetes API server.
In a pipeline or other automated process, you want to logon non-interactively. That is possible via the client-go credentials plugin kubelogin. When you search for kubelogin, you will find several of those plugins. You will want to use Azure/kubelogin to logon to Azure AD. In the video above, I demonstrate the use of kubelogin around the 14:40 mark.
baeke.info 
This is great article . I would be happy if you cover in a different blog post , or even here the following :
1. the “–enable-azure-rbac” part of the AAD authentication and how it can replace the admin-group Id’s
2. how can we address the fact that when using –admin , or when providing device-code and authenticating , the config file is being updated with sensitive information , how can we prevent that ? is there a way to ask for a short-lived token ? is there a way not to store the token when we authenticate with aad ? I guess RBAC might have some answers here …..
3. also forgot to mention that we want to get out from SP with user/password , so question is whether kubelogin can be used with Managed Identity that has role access to the cluster, and I guess the answer is yes.
Thanks for your comments. Regarding MI, that is certainly possible. One way of doing it is using MI with az login and then use kubelogin with az cli. I am not sure if kubelogin supports MI directly.