In the last post, we wired up workload identity on an Azure Arc-enabled Kubernetes cluster and pulled a secret out of Key Vault without a single credential going anywhere near the pod.

Which was very satisfying… and also completely useless, because all that pod did was print a secret to the console and then die.

So let’s fix that. I want to take the exact same trust relationship and put it behind something I would actually run - a PowerShell workload, on a schedule, doing real work against Microsoft Graph. No app registrations, no client secrets rotating every six months, no certificate quietly expiring at 2am on a Sunday.

In the last post, we connected a local Kubernetes cluster to Azure using Azure Arc so that we could manage it from the Azure portal.

Which is cool, but if all we do is stare at our cluster from Azure, we are missing the fun part.

What I really want from this setup is the ability to run workloads locally that can authenticate to Azure resources in the same way they would in a “real” environment, without me having to stuff secrets into config files or pass credentials around by hand.

Over the last few years, my focus at work has migrated away from Intune and device management to software engineering and the management of cloud native technologies.

This, to the surprise of no one, has been a steep learning curve. One of the big challenges I’ve faced is how to test and develop applications locally in an environment that mimics the production environments that the software will eventually run in.

Microsoft has recently announced a new feature that allows us to use managed identities to authenticate across tenants. This is a big deal, and opens up a new secure way of managing multiple tenants in Azure.

One of the biggest security concerns facing developers today is credential leakage and features like this help alleviate the risk of potentially leaving secrets in source control by removing the need for them entirely!

In this post I’ll show you how to set this up to authenticate to a second tenant in an Azure function app, and how to use it to call the Microsoft Graph API!

In the previous post, we looked at how to apply Graph API permissions to a managed identity. In this post, we’ll look at how to leverage this to make calls to the Microsoft Graph API from an Azure function app.