AKS PodIdentity – ServicePrincipals for K8s Pods – Part 2 (Implementation)

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!

One thought on “AKS PodIdentity – ServicePrincipals for K8s Pods – Part 2 (Implementation)

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

WordPress.com.

Up ↑

%d bloggers like this: