aad-pod-identity Docker-desktop

[AlexPaskhin]

I got setup the recent version of Docker with WSL2 and build-in Docker Kubernetes https://www.docker.com/products/kubernetes .
I found that it is very useful to build kubernetes ready application on the desktop computer.
I am heavily developing for Azure AKS.
I tried to setup aad-pod-identity on Docker Kubernetes. The "mic" component doesn't work for desktop-docker.
I clone the master branch and came through the mic.go. It was a bit surprising to see the hardcoded integration to the cloud Azure provider even you are not using MSI.
For reaching the docker-desktop goal I have created the mic-docker version light without the cloud integration. Putting extra configuration in the existing one, will turn the code into completely unreadable mess.
So, it works fine and smooths.

Is it worth for a team that it will be contributed?
Or, do you have own plans to deliver this solution in future?

[aramase]

I tried to setup aad-pod-identity on Docker Kubernetes. The "mic" component doesn't work for desktop-docker.

@AlexPaskhin Could you elaborate more on the goal here? AAD Pod Identity only works with Azure Kubernetes clusters. MIC component is responsible for assigning/un-assigning the user managed identity which is why it's tightly coupled with the cloud azure provider.

[prabhakarreddy1234]

I'm also looking for similar solution. I have helm charts for my microservices and all pods are using aad pod identity. They get deployed to AKS and works well.

But i would like to deploy the same helm charts to my local docker-desktop kubernetes cluster. They get deployed but MIC fails with below error.

failed to create MIC client, error: failed to initialize cloud provider client, error: failed to config file /etc/kubernetes/azure.json, error: read /etc/kubernetes/azure.json: is a directory

It's not viable to create another set of helm charts for local cluster. It adds additional maintenance.

If it's possible to configure aad pod identity with service principal in local cluster (single node) then when a pod requests an azure service, NMI will check MIC for the identity and gives access to the azure resource.

@AlexPaskhin since you got it to work it might be useful if you submit a pull request and hopefully it gets merged.

[AlexPaskhin]

I have done version of my goals it is here https://github.com/Wallsmedia/aad-pod-identity (Thanks for the brilliant engineering idea).
It gives me opportunity to run Kubernetes outside of Azure cloud, and to work with Azure and provide all features of Aad-pod-identity authentication.
Why do I need it? Did you ever try to Debug something in AKS? If you don't, try it, run Visual Studio, make a break point and debug the code. This experience will be the best answer on the question about goals.

I did explorer the guidance at https://azure.github.io/aad-pod-identity/docs/. I read it many times. The description/spec would disagree with you, there are three modes. For "service principal" you do not need managed identity, so AAD-pod product should support it in no-Azure mode. The mic component do not do that as described in spec. The term it works ONLY in Azure AKS never mentioned there.

[AlexPaskhin]

@aramase
I can prepare pull request. Is it master branch to merge for P-R ?

[prabhakarreddy1234]

@aramase Can you please go thorough above discussion and give a go ahead for PR.

[aramase]

Sorry for the delay.

If the goal is to have pod identity running outside of an Azure Kubernetes cluster and use this for testing with service principal (type: 1 in AzureIdentity), then we offer a managed mode. In this mode, there is only NMI which will perform the validation and fetch a token for SP. If run on Azure Kubernetes cluster, it'll also fetch the token for User-assigned managed identity.

[AlexPaskhin]

Here is the list of goals:

1. Docker Desktop + WSL2 + Kubernetes + Visual Code/Visual Studio is the comfortable development environment for .Net Core + Azure.
2. "Docker-Mic" will be a special component that allows you to simulate AKS and develop component for AKS. AAD-pod identity is the key technology that allows you to address authentication concern for microservices running in Azure.
3. Docker Desktop is not a production environment.
4. "Docker-Mic" is the gateway from non Azure production environment to use Azure production services.
5. When you are using AKS it will be used Managed identity and it will be no any changes in microservices.
6. The AAD pod identity project will have new a room for new ideas and new features.

[kinzleb]

It would be nice if this "Docker-Mic" could also:

• Be used with other local k8s, like Minikube w/ docker driver for example
• Not be limited to WSL2 or Linux hosts but also work when using Docker Desktop on Mac for example
• Allow configuration such that the Mic container could access and use the token of a developer who has logged in using azure cli on their local host so that it is the developer's user identity used to get the token for the identity specified in the AzureIdentity custom resource, rather than requiring something like a shared Service Principal for the whole development team where you would need to be concerned with how developers could securely access the ClientSecret of the Service Principal.

[chewong]

Hi all, if the goal is to have AAD Pod Identity running in a non-Azure environment, the closest we have got is using a service principal credential (stored as a Kubernetes secret) to authenticate MIC (see https://azure.github.io/aad-pod-identity/docs/configure/deploy_aad_pod_dedicated_sp/). Alternatively, as @aramase mentioned, you can skip MIC installation by using the managed mode. Then, you can use type: 1 of AzureIdentity to acquire a service principal token on behalf of your application.

AAD Pod Identity is designed to work with Azure only, with minimal support on non-Azure clusters. This is something we will keep in mind when designing v2.

@AlexPaskhin thanks for opening this issue and creating a PR but maintaining two versions of MICs that work for both Azure clusters and non-Azure clusters (such as Docker Desktop) is out of this project's scope. Closing this issue for now but feel free to open a new issue if you have any questions.