Managed identities concept in Azure - Step-by-Step Execution

Process Flow - Managed identities concept

Create Azure Resource

↓

Enable Managed Identity

↓

Azure assigns Identity

↓

Resource requests token

↓

Azure AD validates request

↓

Token issued to resource

↓

Resource accesses other Azure services

↓

Access granted based on token

This flow shows how an Azure resource with managed identity requests and receives a token to access other Azure services securely without storing credentials.

Execution Sample

Azure

1. Create VM with managed identity enabled
2. VM requests token from Azure AD
3. Azure AD validates and issues token
4. VM uses token to access Azure Key Vault

This example shows a VM using its managed identity to get a token and access a Key Vault securely.

Process Table

Step	Action	Request/Response	Result
1	Create VM with managed identity enabled	N/A	VM created with identity assigned
2	VM requests token from Azure AD	Token request sent	Azure AD receives request
3	Azure AD validates VM identity	Validation successful	Token issued
4	VM receives token	Token received	Ready to access resources
5	VM uses token to access Key Vault	Access request with token	Access granted
6	VM accesses secrets from Key Vault	Secrets retrieved	Operation successful

💡 Process ends after VM successfully accesses Key Vault using managed identity token

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
VM Identity	Not assigned	Assigned by Azure	Validated	Token received	Used for access
Token	None	Requested	Issued	Held by VM	Used to access Key Vault
Access Status	No access	Request sent	Token valid	Access granted	Secrets retrieved

Key Moments - 3 Insights

Why doesn't the VM need to store any passwords or secrets?

Because Azure automatically manages the identity and token issuance, the VM never handles or stores credentials directly, as shown in steps 2 to 4 in the execution_table.

What ensures that only the VM with the managed identity can get the token?

Azure AD validates the VM's identity before issuing a token (step 3), ensuring only the authorized resource receives the token.

How does the VM use the token to access other services?

The VM includes the token in its request to the service (step 5), and the service grants access based on token validity.

Visual Quiz - 3 Questions

Look at the execution_table, what happens at step 3?

A Azure AD validates VM identity and issues token

B VM requests token from Azure AD

C VM accesses Key Vault secrets

D VM is created with managed identity

💡 Hint

Check the 'Action' and 'Result' columns for step 3 in execution_table

At which step does the VM receive the token?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for 'Token received' in the 'Request/Response' column in execution_table

If the VM identity was not validated, what would change in the execution_table?

A Token would still be issued

B Token would not be issued and access denied

C Access to Key Vault would be granted anyway

D VM creation would fail

💡 Hint

Refer to step 3 where validation leads to token issuance

Concept Snapshot

Managed identities let Azure resources get tokens automatically.
No need to store passwords or secrets.
Azure AD validates and issues tokens.
Tokens let resources access other Azure services securely.
Use system-assigned or user-assigned identities.
Simplifies secure service-to-service communication.

Full Transcript

Managed identities in Azure allow resources like virtual machines to access other Azure services securely without storing credentials. When a resource is created with a managed identity enabled, Azure assigns it an identity. The resource then requests a token from Azure Active Directory (Azure AD). Azure AD validates the identity and issues a token. The resource uses this token to access services such as Azure Key Vault. This process removes the need for manual credential management and improves security by using tokens that Azure manages automatically.

Practice

1. What is the main purpose of managed identities in Azure?

easy

A. Allow resources to access other services securely without passwords

B. Store user passwords for Azure services

C. Create virtual machines automatically

D. Manage network traffic between resources

Solution

1. Step 1: Understand managed identities purpose

   Managed identities provide a way for Azure resources to authenticate to other services without needing passwords.

2. Step 2: Compare options

   Only Allow resources to access other services securely without passwords correctly describes this purpose. The other options describe unrelated functions.

3. Final Answer:

   Allow resources to access other services securely without passwords -> Option A

4. Quick Check:

   Managed identities = secure access without passwords [OK]

Hint: Managed identities remove password use for resource access [OK]

Common Mistakes:

• Thinking managed identities store passwords
• Confusing managed identities with VM creation
• Assuming managed identities manage network traffic

2. Which syntax correctly enables a system-assigned managed identity in an Azure resource configuration?

easy

A. "managedIdentity": "system"

B. "identity": { "enabled": true }

C. "identity": { "type": "SystemAssigned" }

D. "identity": "system-assigned"

Solution

1. Step 1: Recall correct identity block syntax

   Azure resource config uses an "identity" block with a "type" property set to "SystemAssigned" to enable system-assigned managed identity.

2. Step 2: Validate options

   "identity": { "type": "SystemAssigned" } matches the correct JSON syntax. The other options do not follow Azure's expected configuration format.

3. Final Answer:

   "identity": { "type": "SystemAssigned" } -> Option C

4. Quick Check:

   Correct identity block syntax = "identity": { "type": "SystemAssigned" } [OK]

Hint: Use "identity": { "type": "SystemAssigned" } to enable system identity [OK]

Common Mistakes:

• Using incorrect property names like "enabled"
• Omitting the "type" key
• Using wrong string values like "system" or "system-assigned"

3. Given this Azure resource configuration snippet:

{
  "identity": { "type": "UserAssigned", "userAssignedIdentities": { "/subscriptions/123/resourceGroups/rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity1": {} } }
}

What does this configuration do?

medium

A. Enables a system-assigned managed identity for the resource

B. Assigns a user-assigned managed identity named 'identity1' to the resource

C. Disables all managed identities for the resource

D. Creates a new user-assigned identity named 'identity1'

Solution

1. Step 1: Analyze the identity type

   The "type" is "UserAssigned", meaning the resource uses an existing user-assigned identity.

2. Step 2: Check the userAssignedIdentities property

   The resource assigns the existing identity at the given resource ID path, named 'identity1'. It does not create a new identity.

3. Final Answer:

   Assigns a user-assigned managed identity named 'identity1' to the resource -> Option B

4. Quick Check:

   UserAssigned with identity path = Assigns a user-assigned managed identity named 'identity1' to the resource [OK]

Hint: UserAssigned type with identity path means assign existing identity [OK]

Common Mistakes:

• Confusing system-assigned with user-assigned identity
• Thinking the identity is created, not assigned
• Ignoring the userAssignedIdentities property

4. You wrote this Azure resource config to enable a system-assigned managed identity:

{
  "identity": { "type": "systemassigned" }
}

Why does this configuration fail to enable the identity?

medium

A. The resource group name is missing

B. The identity block is missing the "enabled" property

C. User-assigned identities require a different syntax

D. The type value is case-sensitive and must be "SystemAssigned"

Solution

1. Step 1: Check the type value case

   Azure expects "SystemAssigned" with capital S and A. "systemassigned" is invalid due to case sensitivity.

2. Step 2: Validate other options

   Stating that the identity block is missing the "enabled" property is incorrect because "enabled" is not required. User-assigned identities require a different syntax, but this config is for system-assigned. The resource group name is unrelated to this error.

3. Final Answer:

   The type value is case-sensitive and must be "SystemAssigned" -> Option D

4. Quick Check:

   Case-sensitive type value = The type value is case-sensitive and must be "SystemAssigned" [OK]

Hint: Check capitalization of "SystemAssigned" exactly [OK]

Common Mistakes:

• Ignoring case sensitivity in type value
• Adding unnecessary properties like "enabled"
• Confusing system-assigned with user-assigned syntax

5. You want two Azure virtual machines to share the same managed identity to access a database securely. Which approach should you use?

hard

A. Create a user-assigned managed identity and assign it to both VMs

B. Assign a system-assigned managed identity to each VM separately

C. Use a shared password stored in Azure Key Vault

D. Enable managed identity only on one VM and share its credentials manually

Solution

1. Step 1: Understand identity sharing options

   System-assigned identities are unique per resource and cannot be shared.

2. Step 2: Identify user-assigned identity use

   User-assigned managed identities can be created once and assigned to multiple resources, allowing sharing.

3. Step 3: Evaluate other options

   Using shared passwords or manual credential sharing is insecure and against best practices.

4. Final Answer:

   Create a user-assigned managed identity and assign it to both VMs -> Option A

5. Quick Check:

   User-assigned identity allows sharing = Create a user-assigned managed identity and assign it to both VMs [OK]

Hint: Use user-assigned identity to share across multiple resources [OK]

Common Mistakes:

• Trying to share system-assigned identities
• Using passwords instead of managed identities
• Manually sharing credentials insecurely