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.