Azure Managed Identity

 


In today’s cloud-first world, security is no longer optional. Applications interact with databases, storage accounts, APIs, and third-party services, all of which require credentials. The traditional way of storing secrets (like usernames, passwords, API keys, and certificates) in configuration files or environment variables is risky and hard to manage.

This is where Managed Identity and Azure Key Vault become powerful security pillars in Azure.

Together, they provide:

  • Password-less authentication

  • Centralized secrets management

  • Strong access control

  • Reduced risk of credential leakage

Let’s understand both concepts in detail and how they work together.


What is Azure Managed Identity?

Managed Identity is an Azure feature that allows your application to authenticate to Azure services without storing credentials in your code.

Azure automatically:

  • Creates an identity in Microsoft Entra ID (formerly Azure AD)

  • Manages the credentials

  • Rotates them

  • Secures them

Your application simply requests a token and uses it to access Azure resources.

Types of Managed Identity

  1. System-Assigned Managed Identity

    • Enabled directly on an Azure resource (VM, App Service, Function App, etc.)

    • Lifecycle tied to the resource

    • When resource is deleted, identity is deleted

  2. User-Assigned Managed Identity

    • Created as a standalone Azure resource

    • Can be assigned to multiple services

    • Lifecycle independent of resources

    • Useful for shared access patterns


What is Azure Key Vault?

Azure Key Vault is a cloud service that securely stores and manages:

  • Secrets (passwords, connection strings, API keys)

  • Keys (encryption keys)

  • Certificates (SSL/TLS)

It provides:

  • Centralized secret storage

  • Access control using Azure RBAC or Access Policies

  • Audit logging

  • Versioning

  • Automatic certificate renewal

  • Integration with many Azure services

Instead of embedding sensitive data in code, applications fetch them securely from Key Vault.


Why Combine Managed Identity with Azure Key Vault?

Traditionally, to access Key Vault, applications need:

  • A client ID

  • A client secret

  • Certificate

But where do you store these credentials securely?
That becomes another security problem.

Managed Identity eliminates this issue by allowing:

  • Applications to authenticate automatically

  • No secrets stored in configuration

  • No credential rotation burden

So the flow becomes:

Application → Managed Identity → Azure AD Token → Azure Key Vault → Secrets

No passwords, no secrets in code.


Architecture Flow

  1. Application runs on an Azure service (VM, App Service, Function, etc.)

  2. Managed Identity is enabled on that service

  3. Application requests a token from Azure Instance Metadata Service (IMDS)

  4. Azure AD validates identity and returns an access token

  5. Application uses token to access Azure Key Vault

  6. Key Vault validates token and returns requested secret

This entire process is secure and automated.


Step-by-Step: Using Managed Identity with Azure Key Vault

Step 1: Create Azure Key Vault

az keyvault create \
  --name MySecureVault \
  --resource-group MyRG \
  --location eastus

Add a secret:

az keyvault secret set \
  --vault-name MySecureVault \
  --name DbPassword \
  --value "MyStrongPassword"

Step 2: Enable Managed Identity on Resource

For App Service:

az webapp identity assign \
  --name MyWebApp \
  --resource-group MyRG

For Virtual Machine:

az vm identity assign \
  --name MyVM \
  --resource-group MyRG

Step 3: Grant Key Vault Access

Using RBAC:

az role assignment create \
  --assignee <ManagedIdentityObjectId> \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/<sub-id>/resourceGroups/MyRG/providers/Microsoft.KeyVault/vaults/MySecureVault

Step 4: Access Secret from Application

Example in Python:

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

vault_url = "https://mysecurevault.vault.azure.net/"
credential = DefaultAzureCredential()
client = SecretClient(vault_url=vault_url, credential=credential)

secret = client.get_secret("DbPassword")
print(secret.value)

No username, no password, no secret in code.


Security Benefits

FeatureBenefit
No hardcoded credentialsPrevents secret leakage
Automatic credential rotationZero manual effort
Least privilege accessOnly allowed resources can access
Audit logsFull traceability
Centralized secretsEasier governance

Real-World Use Cases

  • App Service accessing database credentials

  • Azure Functions calling external APIs securely

  • Virtual Machines accessing encryption keys

  • AKS pods accessing secrets via managed identity

  • CI/CD pipelines fetching secrets dynamically


Managed Identity vs Service Principal

FeatureManaged IdentityService Principal
Credential managementAutomaticManual
Secret storageNot requiredRequired
RotationAutomaticManual
SecurityHigherMedium
ComplexityLowHigher

Best Practices

  • Prefer Managed Identity over Service Principals

  • Use RBAC instead of access policies

  • Grant least privilege access

  • Separate vaults for Dev, Test, and Prod

  • Enable Key Vault logging and monitoring

  • Avoid exporting secrets into files


Common Mistakes to Avoid

  • Storing secrets in environment variables permanently

  • Giving overly broad permissions to identities

  • Using a single vault for all environments

  • Not monitoring Key Vault access logs


Conclusion

Managed Identity and Azure Key Vault together form the backbone of secure identity and secret management in Azure.

They help you:

  • Remove passwords from code

  • Centralize secret storage

  • Strengthen application security

  • Simplify identity management

  • Follow Zero Trust principles

If you are building cloud-native applications, mastering these two services is not optional—it is essential.

Comments

Popular posts from this blog

Azure Archive Storage

Azure Data Engineering Workflow

Medallion Architecture.