Managed Identities - Simply Explained

Have you ever opened a config file and thought, "I really hope nobody finds this connection string" or maybe you've been the person who accidentally pushed a secret to GitHub and spent the next hour rotating keys before anyone noticed? If you've worked with Azure for any length of time, you've dealt with the credential problem. Service principles with client secrets, certificates that expire at the worst possible moment, connection strings spread across repos and deployment scripts. It's a mess. But here's the thing, what if your app didn't need secrets at all? What if you could give it its own identity just like you give a person one and let Azure handle the rest? Think of it like a digital ID card for your app that ID card shows Azure who the app is and what it's allowed to do. And that's exactly what managed identities are all about. In this episode, we're breaking down what they are, the two types you need to know and why Microsoft is betting on this approach for Azure security. By the end, you'll understand why managed identities are becoming the standard for any real Azure workload. The problem, secrets, secrets everywhere. Let's start with the old way of doing things. You build an app that needs to talk to Azure storage so you grab a connection string, then it needs to read from key vaults so you get another secret, then it has to write to a database which means another credential. Before you know it, you're managing a dozen different secrets, each one a ticking time bomb. Security people call this secrets brawl. Those credentials end up in app settings, environment variables, deployment scripts and sometimes hard coded and source code. A quick search on GitHub for accidentally committed secrets shows this isn't just a hypothetical problem. It happens every single day. Then there's the rotation problem. Rotating secrets every 90 days is what security best practices recommend. In theory, that sounds great, but in practice, nobody does it consistently. Teams forget, scripts break and then you have a certificate that expires at 3 a.m. on a Saturday taking your entire production environment down. The human factor makes it worse. Secrets get shared in emails, paste it into chat threads or written on sticky notes attached to monitors. When someone leaves the company, nobody remembers to rotate the credentials they had access to. Now scale that up to a microservices architecture where every component needs its own identity. Suddenly, you're not managing a dozen secrets, but 50. When something goes wrong, good luck figuring out which service did what, because audit logs become useless when multiple services share the same credential. You see an action happened, but you have no idea which service actually performed it. So Microsoft looked at this mess and asked a simple question, what if we just eliminated the secret entirely? The solution managed identity. So here's the idea. Instead of handing your app a secret, it has to keep safe. You give it an identity. A real identity inside Microsoft EntraID, just like a user account, but built for a workload as your creates it, ties it to your resource and handles all the credential management behind the scenes. You never see a password, you never generate a key, you never install a certificate, it just works. Now here's what's interesting. Under the hood, a managed identity is still a service principle. The same kind of object that exists when you register an app in EntraID. The difference is that you don't manage the credential. Azure does. It creates the identity, rotates the certificate automatically every 45 days or so, and if you're using a system assigned identity, it cleans everything up when the resource is deleted. No orphaned accounts, no expired secrets causing outages, no manual rotation scripts that nobody remembers to run. So how does it actually work? The magic happens through something called the Instance Metadata Service or IMDS. Every Azure resource has an internal endpoint at a specific IP address, 169.254, 169.254. When your code needs to authenticate, it sends a request to this endpoint saying, I need a token for Azure storage. The Azure fabric checks that this resource actually has a managed identity enabled, and if it does, IMDS returns and access token, your code takes that token and uses it to call the service it needs. Think about what that means. Your code never sees a secret. It doesn't store one. It doesn't read one from a config file. It just asks for a token and gets one. The Azure platform itself acts as the proof that your app is who it says it is. This changes the entire mindset of building on Azure. The old way was, I need my app to talk to storage, so I need a connection string. The new way is, I need my app to talk to storage. Can I use a managed identity? And in almost every case, the answer is yes. Azure storage supports it, Key Vault supports it, SQL database, service bus, event hubs, Cosmos DB, the list keeps growing. When you're building a new Azure workload, managed identity should be your first thought, not an after thought. No more storing secrets in app settings, no more environment variables with connection strings, no more putting credentials in Key Vault just for authentication. You grant permissions directly to the identity using our back and the platform handles the rest. System assigned versus user assigned. Now let's talk about the two flavors of managed identities because this is where people get confused. They're not the same thing and picking the wrong one can cause headaches later. The core difference comes down to one word, life cycle. Who owns the identity's lifespan? Who decides when it's created and when it's destroyed? System assigned is the simpler of the two. You enable it on a resource, a virtual machine, an app service, a single function, and Azure creates an identity that is tied directly to that resource. They share a life when the resource is born, the identity is born. When you delete the resource, the identity is deleted too, one to one relationship. The beauty of System assigned is that there's almost no management overhead. You flip a switch in the portal or add a single line in your bicep template, and it's done. No separate resource to create, no cleanup to worry about. If you have a single web app that needs to read from its own storage account, this is your answer. Enable it, grant the role, move on, but there's a catch because the identity is tied to that specific resource. If you delete the resource, the identity disappears. That's fine if you're done with it. But what if you're migrating workloads? What if you need to rebuild a VM and want to keep the same identity? With System assigned, you'd have to re-enable it and re-ground permissions. Not a disaster, but an extra step. User assigned solves that problem. Here you create the identity as a standalone Azure resource first. It exists independently with its own life cycle. Then you attach it to one or more resources, virtual machines, app services, whatever you need, one identity, many resources. This is a many to one relationship. The identity lives on its own. You can delete all the resources that use it and the identity stays. You can attach the same identity to five different services and they all share the same permissions. That's incredibly useful when you have a shared development cluster where multiple services all need access to the same key vault. Instead of granting permissions five times to five different identities, you grant it once to a user assigned identity and attach it everywhere. So when do you pick which? Here's a simple framework. Use System assigned when you have a single resource that needs its own identity and you want zero management overhead. A web app that talks to its own database. A function that writes to its own storage account. A VM that needs to pull secrets from key vault, enable it, grant access done. Use user assigned when you need the same identity across multiple resources. When you want the identity to outlive the resources it's attached to, when you need to control the life cycle separately, maybe you want to pre-create identities in a central management subscription and let application teams attach them. User assigned gives you that flexibility. One more thing, user assigned identities are regional resources. You create them in a specific region but the service principle behind them lives in enter ID globally. So you can attach a user assigned identity created in East, US to a resource in West Europe. The identity works anywhere as you are runs. How they actually work under the hood. So what actually happens when your code uses a managed identity? Let's walk through the flow. Your code needs to talk to Azure storage. Instead of reading a connection string from a config file, it calls the identity endpoint. If you're using the Azure SDKs, this happens automatically through default Azure credential. You don't write any special code. You just create a blob service client without passing credentials and the SDK handles the rest. That request hits the instance metadata service at 169.254, 169.254. Think of it like an internal phone number that every Azure resource has. You can't reach it from your laptop that only exists inside the Azure fabric. IMDS then checks with the Azure control plane. Does this resource have a managed identity enabled? If not, you get an error. If it does, the platform confirms the identity. Next, IMDS returns an access token. It's a standard OAuth 2.0 token like any other token from EntraID. It includes the identity's client ID, the target resource and a timestamp. The token is short-lived, typically 60 to 90 minutes. Your code takes that token and calls Azure storage. The storage service validates the token against EntraID and checks the ABIAC permissions you assigned to the managed identity. If the identity has storage blob data reader on that storage account, the request goes through. If not, you get a 403. Here's the thing, at no point did your code handle the secret. The platform itself proved the resources identity. The Azure fabric knows what resources running, where it's running and that it has a managed identity. It's not checking a password. It's checking the resources, existence, and configuration inside Azure compared that to the old service principle approach. You needed three things, the tenant ID, the client ID, and a client's secret or certificate. Your code has to read those values from somewhere. Environment variables, key vault, a config file, every one of those is a potential leak point. Everyone requires manual rotation. Everyone is something an attacker could steal. With managed identities, your code doesn't specify any of that. Default as your credential automatically detects. It's running inside an Azure resource with a managed identity and uses it. If you run the same code locally on your laptop, default as your credential falls back to your personal developer credentials. You don't change the code, you don't change the configuration. The SDK handles the environment detection for you. The tokens refresh automatically. Your code doesn't worry about expiration. The SDK caches the token and requests a new one before the old one expires. This all happens in the background. You just call the service and it works. One thing to be aware of, permission changes don't take effect instantly. Because tokens are cached for up to 24 hours on the back end, if you grant a new R-back role to a managed identity, it might take a while before the identity can use it. This is by design. It reduces load on the authentication infrastructure, but it means you can't expect instant propagation. If you need immediate access, you might need to restart the service or wait for the cache to clear. Real-world scenario from dev to production. Let's make this concrete. Imagine a simple web API that writes to Azure storage and reads secrets from Key Vault. We'll follow it from your laptop to production in development you're running locally. Visual Studio, VS Code, whatever tool you use. Default as your credential kicks in and picks up your personal developer credentials. The same ones you use to sign into the Azure portal. You don't need a managed identity here. You don't need a service principle. Your own user account handles authentication while you're building and testing. Now it's time to deploy. You push your code to Azure app service. First thing you do is enable system assigned managed identity on that app service. One toggle in the portal or one line in your bicep template. That's it. Next, you grant permissions. Your API needs to write blobs to a storage account and read secrets from Key Vault. You assign two R-back roles. Storage Blob Data contributor on the storage account and Key Vault secrets user on the Key Vault. Both assigned to the managed identities principle ID. Notice what you didn't do. You didn't generate a connection string. You didn't create a client secret. You didn't store anything in app settings. You didn't put credentials in Key Vault just to retrieve them later. You granted permissions directly to the identity and the platform handles the rest. The app starts working immediately. No secret rotation scripts. No expiry dates to track. No works on my machine problems because the authentication method changes between environments. Default as your credential handles that transparently. Now you scale out. You add more instances to your app service plan. Every new instance automatically shares the same system assigned identity. You don't need to configure anything. The new instances start serving requests and authenticating with the same identity using the same permissions. It just works. But then you add a second service, a background processor that reads from the same storage account and processes files. This is where user assigned identities shine. Instead of enabling system assigned on the processor and granting the same permissions again, you create a user assigned identity. You granted storage Blob Data Reader on the storage account. Then you attach that same identity to both the web API and the background processor. One permission granted to services covered. Now consider environment isolation. You want separate identities for dev, test, and prod. With user assigned identities, you create three, one per environment. Each one gets permissions scoped to its own resources. A token obtained in dev cannot reach production. Even if someone somehow extracts a token from your dev environment, it's worthless against prod resources. The audience and the permissions simply don't match. Your deployment pipeline itself doesn't need to handle secrets either. The CI/CD runner, whether it's Azure DevOps, GitHub actions, or something else, can use a managed identity to deploy resources and assigned permissions. No service principle secrets stored in pipeline variables. No certificate files uploaded to the build agent. The pipeline authenticates using its own identity, granted through R-Back. The old world versus the new world. Let's put this side by side so you can really see the difference. In the old world, you'd create a service principle, generate a client secret, and store that secret in Key Vault. Then you'd write code to retrieve it at runtime. You'd set up a rotation schedule. Every 90 days, generate a new secret, update Key Vault, test that nothing broke, and hope you didn't miss any of the places that secret was used. That's a lot of moving parts, and one mistake could bring everything down. In the new world, you enable managed identity, assign an R-Back role, and you're done. No secret to rotate. No Key Vault call just for authentication. It's like having a smart badge that works everywhere automatically. That's the magic of it. The old world had a specific failure mode that kept security teams up at night. A developer checks in a secret by accident, and suddenly you have a security incident. You're rotating the secret, notifying the team, auditing who might have accessed it. All hands on deck. In the new world, there are no secrets to check in. The credential doesn't exist in your code base or your config files. It exists only inside the Azure fabric, managed, and rotated automatically by the platform. The old world also had what I call the 3am problem. A certificate expires on a Saturday night. Your production environment goes down. You get paged, you scramble to generate a new certificate, update the service principle, restart the service. Meanwhile, your users stare at error pages. In the new world, Azure rotates the credential for you. Every 45 days or so, the certificate behind your managed identity is replaced automatically. You never even know what happened. No outage, no 3am phone call. The security implications go deeper. Managed identity tokens are tied to the Azure control plane. They're fishing resistant because there's no user involved. The token is obtained by the resource itself through a channel that only exists inside Azure. If an attacker breaches your app, they can access what the identity has permission to access, but they can't steal the credential because there's nothing to steal. And governance gets simpler, too. When you delete a resource with a system assigned identity, the identity is automatically cleaned up. No often service principles lingering in enter ID with permissions you forgot about. No audit findings asking why an identity from a decommissioned project still has contributed access to a production subscription. The platform handles the cleanup. That's the kind of simplification that makes Azure security easier to manage. When not to use managed identities. So if managed identities are so much better, why doesn't everyone use them for everything? The hard limitation is that managed identities only work inside Azure that on-premises backup server in your data center. It can't use a managed identity because it's not running on Azure. There's no IMDS endpoint for it to talk to. Same for your self-hosted GitHub actions runner. If it's not an Azure resource, you need a traditional service principle with a client secret or certificate. Multi-cloud setups run into the same wall. If you have workloads on AWS or GCP that need to authenticate to Azure, managed identities won't help. Those services aren't inside Azure's fabric, so they need service principles. Third party SaaS tools that need to authenticate to your Azure resources, same problem. They're not running on your Azure subscription. They can't use your managed identities, but Microsoft is making progress here. Workload identity federation lets external services exchange their own identity tokens from GitHub, Kubernetes, or other identity providers for intra-ID tokens. It's not as seamless as a managed identity, but it's a step toward reducing secrets everywhere, not just inside Azure. Here's the rule of thumb. If your workload runs on Azure, use managed identities. If it doesn't, use service principles with key vault and automated rotation. And keep an eye on workload identity federation. It's closing the gap for workloads outside Azure. Actionable takeaways. So what can you actually do starting today? Here are a few simple steps that will make a big difference. First, go through your existing Azure resources, app services, functions, VMs, anything that supports managed identities. If you find one without managed identity enabled, turn it on. It takes seconds and it costs you nothing. No reason not to do it. Next, pick one specific service to convert. Storage or key vault are perfect candidates. Replace that old connection string sitting in your app settings with a managed identity and an R-Backroll assignment. Run a quick test. You'll see how much cleaner your configuration looks when there are no secrets hiding in plain sight. Finally, for any shared infrastructure like a development cluster or a set of microservices that all need the same permissions, use a user assigned managed identity instead of duplicating permissions across multiple system assigned identities. One identity, one set of R-Backrolls, and you can attach it everywhere it's needed. It's that simple. This isn't just a nice to have anymore. Microsoft is making mandatory MFA mandatory for service principles, but managed identities bypass that requirement completely because there are no user credentials to protect. Your future self will thank you when you avoid that 3am on call alert about an expired certificate. Managed identities let you give your apps their own identity without ever touching a secret. That's the real shift from managing credentials to managing permissions. Subscribe for more simply explained breakdowns and drop a comment letting me know which as your service you want covered next, making Microsoft make sense one nugget at a time.