May 20, 2021 4 min read

Secretless applications: managed identities

An introduction to Managed Identities, both System Assigned and User Assigned. What are they, why would you use them?

Secretless applications: managed identities
While listening to the Secretless Apps with Christos Matskas episode on the M365 Developer Podcast it reminded me that still a lot of developers have no clue about Managed Identities and their advantages. Additionally, there were some unanswered questions in that episode that I could answer in a couple of blog posts. Thus a new series is born!

I can recommend a listen to the above-mentioned podcast episode as it will give a basic understanding of what we are trying to achieve here. The episode is focused on Managed Identities as an alternative to a plain old regular App Registration (and thus Service Principal) for doing authentication from your application to another resource. Why would you need an "alternative" approach when App Registrations work just as well? The answer is simple: because they don't! I'll illustrate with the following use case: you have a website on Azure App Service and it needs to connect to an Azure Service Bus. How would you approach that?

Option 1: Client ID and Client Secret
Let's create an App Registration, and now you have a Client ID and a Client Secret. After that, you assign permissions to the App Registration on the Service Bus. You decide to store the Client ID and Secret in the app settings of the App Service so you can read both from code. You aren't too happy about having your secret in plain text in the app settings ☹.

Option 2: Client ID and Client Secret in a Key Vault
You have a magnificent idea and you start similar to Option 1, but now you store the secrets in a Key Vault so everything is super secure. Problem now: how do you make the App Service securely connect with the Key Vault? If you store the connection string in the app settings you're in a similar place as Option 1... ☹

Solution: Managed Identities

Managed Identities are created exactly for this purpose: help Azure resources securely connect to other Azure resources. A Managed Identity is associated with one or more Azure resources and effectively gives an Azure resource an identity in Azure Active Directory. The identity and the resource are so tightly coupled that for all intents and purposes can be considered one, thus allowing the resource to authenticate "as itself" to another resource.
With a Managed Identity, you still get a Client ID but no more Client Secret or Certificate. They are very sensitive pieces of information and are now managed transparently in the background by Microsoft. It's both an advantage as a disadvantage: you don't need to manage them yourself anymore and thus can't lose them or need to regenerate them from time to time, but you also can't use them to manually create the connection and request access tokens.
This is resolved by using Azure Identity SDK's in your code, which means both the source resource and the target resource needs to support managed identities. More on this in a later blog post!

System assigned

There are two types of Managed Identities, the first one being a System Assigned Managed Identity. In this case, a Managed Identity is created on a specific Azure Resource (like a Logic App or a Function App) and both are connected for the lifetime of this Azure resource.
A System assigned Managed Identity is directly attached to a specific Azure resource and cannot be attached to other Azure resources. If you only use System Assigned Managed Identities, all your Azure resources will have their own "identity" in Azure AD and you will have to manage the permissions for each of them separately.

User assigned

A User Assigned Managed Identity on the other hand is a "shared" Managed Identity. You create it as a separate resource in Azure, so it shows up in your list of resources inside a Resource Group and you can assign it to more than one Azure resource!

A User Assigned Managed Identity in the Resource Group
Associate a User Assigned Managed Identity to an App Service

All resources that share the same User Assigned Managed Identity also share the permissions that are assigned to it, thus simplifying the permission management a lot as opposed to using System Assigned Managed Identities.

Conclusion

Managed identities make your applications more secure when authenticating to other Azure resources or other APIs that are registered with Azure AD. Keep reading for more tips and tricks, useful scripts, and reasons why you should try and use Managed Identities for as many scenarios as possible!
And best part: they are free with your Azure tenant, so no excuses to start with them now!

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Yannick Reekmans.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.