3.1.3. Implement Managed Identities

First Principle: Managed Identities fundamentally provide Azure services with an automatically managed identity in Entra ID. This enables secure, passwordless access to other Azure resources, eliminating the need for developers to manage credentials in code and greatly enhancing security posture.

What It Is: "Managed Identities for Azure Resources" is a feature of "Entra ID" that provides Azure services with an automatically managed identity. This identity allows services to authenticate to other Azure resources without managing credentials in code.

Visual: "Managed Identities Authentication Flow"

Loading diagram...

Types of Managed Identities:

• "System-assigned managed identity": Created and tied to a specific Azure resource (e.g., VM, App Service, Azure Functions). It is automatically deleted when the resource is deleted. This identity is unique to the resource and cannot be shared.
• "User-assigned managed identity": Created as a standalone Azure resource. It can be assigned to one or more Azure resources, and its lifecycle is independent of any resource it is attached to. This enables identity reuse across multiple resources.

How managed identities work: When an Azure resource with a "managed identity" needs to access another Azure service (such as Key Vault, Storage, or Cosmos DB), it requests an "OAuth 2.0 token" from "Entra ID". The resource then uses this token to authenticate securely to the target service, without embedding secrets or credentials in code.

Security benefits:

• "No credentials stored in code or configuration": Eliminates the risk of hardcoded secrets.
• "Automatic credential rotation": Azure manages the lifecycle of the identity's credentials, including automatic rotation, enhancing security hygiene.
• "Access control is integrated with Entra ID roles and policies": You use standard "Role-Based Access Control (RBAC)" to grant the "managed identity" specific permissions to target resources.

Example: An Azure App Service with a "system-assigned managed identity" can be granted access to read secrets from Azure Key Vault. The app requests a token from "Entra ID", then uses it to call "Key Vault"—no secrets are exposed or managed manually.

Scenario: You have a new Azure Function that needs to write data to an Azure Cosmos DB database. Your security team mandates that no database connection strings should be hardcoded in the function's configuration or code. You need a secure, automated way for the function to authenticate to Cosmos DB.

Reflection Question: How do Managed Identities (system-assigned or user-assigned) fundamentally provide secure, passwordless access for Azure services to other Azure resources, eliminating the need for developers to manage credentials and greatly enhancing security posture?

💡 Tip: Prioritize using Managed Identities whenever an Azure service needs to access another Azure service. It's the most secure and operationally efficient method for "service-to-service authentication".