If we go to the Azure portal, I've already got a container registry set up with a misspelled repository in it. What I'll do now is create an AKS Kubernetes two node cluster using Azure's CLI with the az aks create command. The last argument is attach acr, so AKS knows where to pull the container images from. While we're here, I wanna point out a bit of a glitch or problem that I had, and after some research found that I wasn't the only one.

I initially tried to attach an existing cluster to my container registry with the az aks update command and kept getting an error of could not create a role assignment for ACR. Are you the Owner on this subscription? I'm not the owner, and I'm guessing most Azure users aren't a subscription owner either. But I could attach to the container registry if I did it while creating the cluster. Strange, but there you go. 

Okay, having created the cluster, let's get the service principal's client ID. Going back to the portal and looking at active directory app registrations, we can see it there. Next, I need to get credentials so I can start using the kube control commands. Because I've been through this process before, when I couldn't get AKS to attach to an existing cluster to my repository, I'm being asked if I wanna overwrite previous configurations which I will say yes to.

Now I'm going to apply the deployment RBAC yaml file of Azure active directory pod identity project to make my Kubernetes cluster aware of Azure managed identities. Having done that, I'm now going to create a managed identity which I will use to access the key vault. With the new managed identity created, I'm gonna give it access to read secrets from my key vault. So go into access policies through add access policy and from the template, I'll select secret management. Then in terms of permissions, I'll just set get and list.

Now search for my newly created identity and add it, and crucially, don't forget to save. So back at the CLI, I'm going to apply an Azure identity yaml file to my AKS set up. This file has the client ID of my managed identity as well as the resource ID. The meta data name doesn't necessarily have to be the same as the name of the managed identity. We're going to use that reference later in a binding file.

Okay I'll just apply the active directory pod identity yaml file. The next step is to bind that identity to our Kubernetes cluster with an Azure identity binding file. So I told the binding file about the managed identity yaml file and now I apply that binding file to my cluster. Here's the service principal ID that I created. I'm now going to do a role assignment of managed identity operator to that ID. Then apply my config map yaml file. And here I'm telling my deployment file all about the identity binding.

Finally I will apply my deployment file. Next I'll get my external IP address and will bring up the app in the browser. So if I go back into my configuration file, my config map file, and change the background color to red. And I'll go back to the key vault and replace the secret with another value. Just have a look at that changed value.

There we go, this is a changed secret. Back to the Azure CLI and I will apply the new config map file. I'll restart my container and will go back and refresh, and there we go. We got the red background and the updated secret value.