Do you use Managed Identities in your Azure projects?

Teams often unknowingly create security risks by storing secrets in configuration files, DevOps variables, or - even worse - accidentally committing them to Git 😱. This leads to production outages, broken deployments, and painful key rotations that waste time and cost money. Even when Key Vault is used, many rely on static secrets, which still require manual rotation and management. Thankfully Azure has a much safer way of solving this problem.

How to use Managed Identity in your project

What is a Managed Identity?

A Managed Identity is an identity that Azure creates and manages for your resource so it can authenticate securely without storing any credentials.

Azure automatically handles:

• Password and secret rotation
• Identity lifecycle
• Secure authentication to Azure services

This means no more stored secrets, ever.

📚 Learn more - Microsoft official documentation

Why Managed Identity is always better

Using secrets (even when placed in Key Vault as static keys) creates manual work and security gaps. Managed Identity removes that entire problem space.

✅ Benefits

• Eliminates all secrets and keys
• More secure – nothing to leak
• Integrates with Azure RBAC
• Supported by all Azure SDKs
• Automatically rotates
• Free

RBAC – fine-grained, auditable access control

Managed Identities work hand-in-hand with Azure Role-Based Access Control (RBAC). Instead of sharing a connection string or secret, you assign a specific role to the identity on the target resource (e.g. Key Vault Secrets User, Storage Blob Data Reader).

This means:

• Least privilege – each identity gets only the permissions it needs
• Auditability – access grants are visible in Azure IAM, not buried in config files or DevOps variables
• Easy revocation – remove a role assignment and access is gone instantly, no key rotation needed

System-assigned vs user-assigned Managed Identity

Use system-assigned identities for simple 1:1 scenarios, where one Azure resource has its own identity. Use user-assigned identities when the same identity needs to be shared, reused, or managed separately across multiple resources.

More details: Do you know when to use system-assigned vs user-assigned managed identities?

Code example – Connect to Azure App Configuration using Managed Identity

Example from the video:

var appConfigEndpoint =
    builder.Configuration["AppConfig:Endpoint"]
    ?? throw new InvalidOperationException("App Configuration endpoint not set");

var clientId =
    builder.Configuration["ManagedIdentity:ClientId"]
    ?? throw new InvalidOperationException("Managed Identity client ID not set");

builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(
        new Uri(appConfigEndpoint),
        new DefaultAzureCredential(
            new DefaultAzureCredentialOptions
            {
                ManagedIdentityClientId = clientId
            }));
});