Azure Managed Identities - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. As your app probably has a password written into its settings right now, every database, login, API key, and secret copied into a config file is a key left out in the open, and millions of them leak every year. Microsoft built a way for that app to prove who it is, with no stored credential at all. It's called a managed identity, and it works on virtual machines. App service functions and a long list of other Azure services. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. Today, we're digging into Azure Managed identities, and by the end, you'll see how your app gets a token, how Key Vault opens without a password, and the traps that catch beginners.

0:44 Why secrets in code are a problem. Start with the setup that gets almost everyone into trouble. Your app needs to read from a database, drop a file into a storage account, or call another service so it has to prove who it is. Somewhere along the way, a password, a key, or a connection string gets created and handed to the app. That secret usually ends up in a config file, an environment variable or straight into the code itself. It works, and for a while nobody thinks about it. Then it bites you. A secret in your code doesn't stay in your code. It gets committed to source control, and even if you delete it in the next commit, it stays buried in the history. Git keeps everything the same secret, gets screenshotted into a chat, pasted into a ticket, or baked into a container. Image by accident. Security researchers scan public code repositories around the clock looking for exactly this.

1:27 The scale is hard to ignore. Gitguardian is state of secret sprawl report found that close to twenty nine million new hardcoded secrets were pushed to public GitHub in a single year, up about thirty four percent from the year before. GitHub's own security team counted thirty nine million secret leaks in twenty twenty. For one academic study that looked at more than eighty million files, found that up to a third of projects were at risk. This isn't a small, embarrassing mistake that only careless people make, either. The Capital One breach involved stolen cloud credentials, and it ended in a one hundred and ninety million dollars settlement. So the honest version of the story is that the secret itself is the weak point. You can move it into a vault, and that's better than leaving it in code. But you still have a secret to fetch, store, and rotate. Picture an app that never had to hold a key at all and never had one to lose.

2:11 What a managed identity actually is. And as your managed identity is a way for a resource to log into other services without a password, you switch it on for something like a virtual machine or a web app, and Azure creates an identity for it. Inside Microsoft Entra ID the same directory that holds your user accounts. From then on, that resource is a real identity in the directory, and you grant it access the same way you'd grant access to a person. Microsoft describes the benefit in plain terms, you don't have to manage credentials and the credentials aren't even accessible to you. That last part matters because the secret you can't see is a secret you can't accidentally paste into a chat. So the shift is easy to say and big in practice. Instead of your app holding a secret and proving it belongs, the app becomes the identity. Access gets granted to the identity, not to a shared key that anyone could copy.

2:54 A few things matter right away. Managed identities are free to use, and they work with anything that accepts Microsoft Entra sign in behind the scenes. Azure handles the credential for you and rotates it on a schedule, so there's nothing for you to remember or renew the same identity that reads the secret can also read a database row or drop a file into storage, as long as you've granted it the right role. One thing people mix up is that a managed identity isn't the same as an app registration. An app registration has two parts in the directory an application object, and a service principle. While a managed identity only has the service principle because there's no app to register, it's just an identity that Azure created for your resource that's the core of it. Your app has a name in the directory, and it can ask for access using that name instead of a password. The next question is which kind of identity to give it, because there are two and they're not interchangeable.

3:37 System assigned and user assigned. Azure gives you two kinds of managed identity, and the names tell you most of what you need to know. A system assigned identity is created as part of the resource itself. You turn it on for a virtual machine or an app, and the identity is born with it and dies with it. Delete the resource and Azure deletes the identity for you automatically. The catch is that only that one resource can use it, and its name always matches the resource name. A user assigned identity works differently. You create it on its own as a standalone thing in Azure, and then you attach it to one or more resources. It has its own life, so it doesn't disappear when a resource does, and you delete it yourself when you're finished with it. That leaves the question of which one to pick. And Microsoft has a clear recommendation, which is that user assigned identities are more efficient in more situations, and they're the recommended type for Microsoft services.

4:23 The reason comes down to how much bookkeeping you create. Picture four virtual machines that all need to reach two storage accounts. If each machine has its own system assigned identity, you end up making eight role assignments, one for each machine on each account. If all four share a single user assigned identity, you make two. You get the same access for a quarter of the work, with far less to keep track of when people leave and machines get rebuilt. There are situations where user assigned is the obvious pick. If you spin resources up and down quickly, like short lived test environments, system assigned identities can pile up and hit rate limits and Azure starts rejecting requests. A shared user assigned identity avoids that. The same goes for identical resources that need the same permissions. And for cases where you need the identity to exist before the resource does so, you can grant access upfront.

5:07 System assigned wins in two spots. If your logs need to show which specific resource did something. System assigned gives you that because every resource carries its own identity. And if you want permissions to vanish the moment the resource is deleted, system assigned handles that for you. You don't have to choose forever either. A single resource can carry both a system assigned identity and one or more user assigned identities at the same time, which is handy when you want a shared identity for the common jobs and a private one for the sensitive ones. So the practical rule is to start with a user assigned identity. Unless you have a specific reason to want the identity to live and die with a single resource. How your app gets a token an identity doesn't do anything until your app uses it, and the way it works has one twist that surprises almost everyone.

5:49 There are four steps, and they're worth saying out loud. First, you create the identity, either system assigned or user assigned. And second, if it's user assigned, you attach it to the resource that needs it, like a web app or a virtual machine. Then come the last two steps. Third, you grant that identity, access to whatever it needs to reach, which will come to in a moment. Fourth, your app uses the identity from code, and that step is the one that matters because there's no password anywhere in it. Your app asks a local endpoint for a token, and the platform answers based on where the code is running on a virtual machine. That endpoint is the Azure Instance metadata service, which lives at a special address. One sixty nine point two five four one sixty nine point two hundred and fifty four. That address is only reachable from inside the resource, and the request has to include a metadata header that helps block forged requests in app service and Azure Functions.

6:37 The idea is the same, but the address is different. Azure hands the app a local token endpoint through a couple of environment variables, and the app calls that. Instead the address changes, but the idea doesn't. And either way, the app never sees a password. Either way, the app sends a request naming the service it wants to reach, and Azure replies with a token. That token is a bearer token, which simply means whoever holds it can use it, and it expires in about an hour. Microsoft's own example shows a lifetime of roughly three thousand six hundred seconds. Most developers never touch any of this by hand. They use a library like the Azure Identity Library or the Microsoft Authentication Library, and it handles the request, the token, and the refresh for them. The developer writes a line of code that says, use the identity and the plumbing disappears.

7:18 The part that catches people off guard is that there's a credential behind all of this, and you never see it. Azure manages it as a certificate, and it expires every ninety days and gets rolled after forty five. You don't store it, you don't copy it, and you don't rotate it. That's the whole point of granting access with role assignments. Getting a token proves who your app is, but it doesn't decide what the app can do. That's the job of a role assignment, and it's the step beginners skip most often. Think of it in two parts. The token is the app's ID and the role assignment is the permission slip. You take the identity and give it a role on a specific resource like reader, on a storage account or a secrets role on a key vault, you choose the scope two. So the role can apply to a single resource, a whole resource group, or an entire subscription without that permission slip.

8:00 The app can show up with a perfect ID and still get turned away at the door. This is where a lot of people get stuck because they enable the managed identity, run their code, and watch it fail. Nothing is broken. The identity simply doesn't have access yet, so Azure denies the request. When you hand out that access, give the smallest role that does the job. Microsoft is blunt about this. If your app only needs to read from a storage account, don't give it right access as well. And whatever you do, don't make the identity a contributor on an entire subscription because every extra permission widens the damage. If that identity is ever compromised. Security people call that the blast radius, and the goal is to keep it small. The good news is that this is mostly a point and click job. In the Azure portal, you open the target resource, add a role assignment, and pick the identity you created with no code required so the pattern stays consistent.

8:45 Create the identity, give it a role, and only then let your app use it. The token comes first and the permission comes second. Reaching key vault without a password. The example that makes this click for most people is Azure Key Vault. Key vault is where teams keep their secrets, keys, and certificates. The usual pattern goes like this. You store your database password in the vault, which is smart, but then your app needs a password to get into the vault. You've solved one problem and created a smaller copy of it. And now there's a secret guarding your secrets. A managed identity breaks that loop. Your app asks for a token for key vault, and because you gave the identity a role on that vault, it can read the secret directly. There's no password, no connection string, and nothing stored in the app's settings. One detail trips people up here, and it deserves repeating.

9:26 A valid token on its own isn't enough. Microsoft says it plainly that Key Vault rejects your calls even when you use a valid token if the identity hasn't been granted access to that vault. So the token and the role assignment have to line up. And if you remember nothing else about access, remember that once they do line up, the app reads its secret and gets on with its day, and there's no credential for anyone to leak. A new developer on your team never gets handed the database password because the password was never sitting on a laptop to begin with. That's the moment the whole idea stops being abstracted where managed identities work. By now you might be wondering whether this only works for some narrow setup. It doesn't, because the list of services that support managed identities is long. Microsoft's own list includes Azure App Service and Azure Functions, virtual machines, and virtual machine scale sets, and Azure Kubernetes Service.

10:10 It also covers container apps and container instances, logic apps, Data Factory, Event Hubs, Service Bus, Azure SQL, Azure storage accounts, along with plenty of others. If you're running almost anything on Azure. Chances are good that it can carry a managed identity. The rule underneath the list is simple managed identities work with services that accept Microsoft Entra sign in, and as more services adopted, the list keeps growing, so check the current documentation for whatever you're using. There's a bonus here that beginners often miss, which is that it goes beyond reaching Microsoft services. Your own application can be the target, too, as long as it accepts Microsoft Entra tokens. That means your internal API can trust a managed identity the same way it would trust a user login without you building a separate password system for it.

10:51 It also means you don't have to hand out shared passwords to other teams, which is one less secret floating around your organization so the reach is wide. Virtual machines, web apps, functions, containers, and the data services behind them can all use this, which is why it has become the default answer for how cloud apps should prove who they are. The pitfalls to watch for. Nothing comes free of trade offs, and managed identities have a few sharp edges worth knowing before you lean on them. The first is that the security boundary is the resource itself. In Microsoft's words, any code running on a virtual machine can request tokens for any managed identity on that machine. So if someone can run their own code on your resource, they can act as the identity with all of its permissions. That isn't a flaw. Exactly.

11:31 It's the design, but it means the identity is only as safe as the resource it lives on. That leads straight to the second trap, which is the escalation path. If you let someone run code on a resource that has a managed identity, you've effectively handed them everything that identity can reach. Microsoft gives a clear example a managed identity with read and write. Access to a storage account is attached to a logic app, and now anyone who can run code in that logic app can read and write that storage account, even if they never had direct access to it. Be careful who can run code where. The third thing is that permission changes take time, and this is the one that sends people hunting for a bug that isn't there. Azure caches tokens for around twenty four hours. So if you change a role assignment, it can take hours for the change to actually take effect. You can't force a refresh, which means a fix you just made might not show up until later.

12:13 And that's confusing if you don't know it's coming. Fourth, managed identities don't cross tenants. They don't work across different directories, so you can't use one to reach a resource in someone else's tenant. And if you move a subscription into a new directory, the identities don't come with it. You have to recreate them and grant access again. Finally, watch the cleanup. Deleting a managed identity doesn't delete its role assignments, so you'll see leftover entries that say the identity wasn't found and those should be removed by hand. Deleting an identity doesn't instantly kill the tokens it already handed out, either because those stay valid until they expire. That window is usually about an hour, but keep it in mind. There are a couple of smaller gotchas as well. Managed identities aren't available for apps deployed in Azure Arc, and the Azure Cloud Services Classic platform doesn't support them at all.

12:55 None of this should scare you off, because these are the details you learn once and then build into how you deploy. And they're far cheaper than a leaked key. A quick recap and one question. So here's the whole thing. In a few sentences, a managed identity swaps a stored secret for an identity that Azure creates and maintains for you. You choose system assigned when you want the identity to live and die, with one resource and user assigned when you want to share it and manage it separately. You grant access with a role assignment, and only then does your app ask a local endpoint for a short lived token. It never stores. The one idea worth sharing with you is that the real win is removing the secret, not hiding it better. So there's nothing to leak, nothing to screenshot, and nothing to forget to rotate. Now here's my question for you. If your app never had to hold a password again, what's the first thing you'd stop worrying about?

13:38 If you want more Microsoft topics explained without the jargon, subscribe to M365 FM and I'll see you in the next one.