From Part 1 you should know a bit about what PodIdentity is, and why it’s an important addition. In this Part, we’ll set out the basics of adding it, and then using it, with an example.
1. Create your identity
This is the identity that you would like your pods to assume. It’s also what you will be granting access to your resources in Azure.
az identity create -g myresourcegroup -n myidentity -o json
In here, the resource group you create it in does matter somewhat. While you’re starting out, apply it to the same one that your ClusterNodes are in.
Make sure to note down the “id” and “client” fields that are returned, we’ll need those in step 3.
At this point, you should also grant your identity access to the relevant Azure Resources. I’d suggest an Azure SQL instance for testing as that’s the example we’ll use. I won’t cover how to do that here.
Note: you should repeat this step for each unique identity that will be applied to pods.
2. Deploy common resources
Luckily, Microsoft have provided a HelmChart to make things a little easier.
helm install --name pod-identity aad-pod-identity/aad-pod-identity --namespace aad-broker
This will put these resources into the “aad-broker” namespace, to keep things a little more segregated.
I advise not mapping the identities using the Chart. To me, these are separate things that have different trigger points.
The Azure Team have used some good, sensible, defaults here. So unless you need something a lot more bespoke then stick with them.
Security Note: The part to look into when you go-live is whether or not the broker should use the Cluster’s credentials for brokering access, or whether you should use a specific ServicePrincipal for that. There could be some good upsides to using it’s own Principal, but there will be extra complexity around setting up access. I advise you make it work without that first, then implement it afterwards, or in the further environments.
3. Create the Identity Resources
For each of the resources you’ve created in step 1, you’ll need to create a AzureIdentity, and a Binding to find the pods.
Create a folder for your identities somewhere e.g. identityconfig
Create an Identityfile <name>-aad-identity.yml
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentity
metadata:
name: <a-idname>
spec:
type: 0
ResourceID: /subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>
ClientID: <clientId>
The ResourceId and ClientId can be retrieved from what you recorded in step 1.
The name here does not HAVE to match your Azure Identity. However, I would advise at this stage, you do that to maintain some consistency.
Create an IdentityBinding file <name>aad-identity-binding.yml
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentityBinding
metadata:
name: <name>
spec:
AzureIdentity: <a-idname>
Selector: <label value to match>
This is where we add in our selectors. For Selector, this is the value you will add to your pod. I would advise that again, you use the same name as the identity. There are much more complicated use cases you can use for this (such as multiple bindings to a single identity), but save those for when you’ve mastered it.
Repeat the above for all the identities.
Apply these to the cluster
kubectl apply -f identityconfig/ -n aad-broker
Note that we’ve put these in the aad-broker namespace. This is a specific choice to organise these. The broker works across all namespaces by default, so putting them in there will keep things contained.
4. Create your Pods
Now the above resources are in place, you can create yourself a pod that will have access.
The key is ensuring that you add the correct label to your Pods/Deployments.
apiVersion: v1
kind: Pod
metadata:
labels:
aadpodidbinding: <binding-selector>
For deployments, you’ll need to put this in the template for the pod.
5. Debugging
Once your pod is created, you’ll want to be able to see if your mapping etc. has worked. There is nothing you can see from your pod, however, there is a secondary resource created to “Map” the identity to the pod.
kubectl get AzureAssignedIdentities --all-namespaces
From there, you should see an entry with the name {pod}-{identity}. If you see that, the binding part has worked
Conclusion
From here, you can now use your pods in the same way you would an Azure Function, or an application running in a VM. For instance, you can use the AzureServiceTokenProvider class in dotnet to get tokens and apply them to SQL connections.
conn.AccessToken = await (new AzureServiceTokenProvider()).GetAccessTokenAsync("https://database.windows.net/");
or use the Azure CLI.
It’s relatively simple to setup and massively powerful!
MartinDotNet 