Azure Managed Identity

What is it?

Still storing clear text credentials or tokens in your app? PLEASE STOP! You are putting your environment at huge risk. Look no further than Azure Managed Identity to make things more secure.

Credentials should be treated like radioactive material. You shouldn't really handle it. If you have to manually handle it you probably aren't managing it properly either, but if you are you should be VERY careful with it. It's radioactive!

We are now in the age where we shouldn't be handling them. There are many reasons why this is a risk, such as having secrets in clear text for malicious users to steal, or having to rotate tokens or credentials which may ultimately end in your automation piece falling over if it's not updated.

Service accounts are something that I've used for a while, but still, I've cracked passwords for service accounts and they've also locked out in the past. These accounts also need to be manually cleaned up after the process/resource it's used for has been discontinued. This is usually something overlooked...

In Azure there's modern methods to manage identiy for us and that is Azure Managed Identity.

How it works

It's pretty simple. Whatever you can create in Azure that needs to be able to access another service in Azure that supports AAD authentication, then managed identity can be used. WITHOUT HAVING TO MANAGE ANY CREDENTIALS! This means you don't have to (not that you should) store any tokens, secrets or any credentials in your app, which will for most people be in clear form. A managed identity is essentially another resource which sits inbetween your app and your target app in which to pull or push data.

There's two types of managed identities

System-assigned

You can enable system-assigned managed identity directly on a resource. When you do this an Azure AD identity is created and tied to the "lifecycle" of that resource or service. This means, if you delete this resource/service/app, then the identity goes with it automatically! Remember what we said about service account cleanup previously? This takes care of that. We don't have that risk of old live service accounts with weak passwords left behind and we don't have to think about cleaning them up either.

User-assigned

You can create them manually, which is absolutely fine and I do this often. This is not tied to a particular instance, as above, which means it won't be removed after you delete the resource it's tied to.

I'm currently a fan of these right now, because the benefit of creating a user-assigned identity means you can have many apps to one identity. This is particularly useful for what I'm working in right now - logic apps.

Example: Logic App -> Graph API

Accessing Graph API without a user and without manging credentials manually with a user-assigned managed identity. Please note, there are a few methods of accessing Graph API from your apps but this so far I find to be the simplest. I will write more posts on the other methods so keep an eye out for those.

There are just a few things to follow in order to use this method and access Graph API:

Create a managed identity instance, either system or user-assigned. In my examples I'm using user-assigned. Why is this? Because you can use multiple logic apps (or others) and use the one identity. If you have a system-assigned, this is tied to the one app

Add Graph API permissions to the managed identity. Unfortunately, for Graph API, this is not possible through the portal! So this has to be added via Powershell. I cover this in another post.

Call managed identity from your app

Take note, with user-assigned you can use the identity in multiple apps to access Graph API.

Read a bit more about accessing Graph API with managed identity here