Azure IAM from Basics | Azure Managed Identities Demo with Microsoft Entra

This comprehensive study note explores Azure Identity and Access Management (IAM), breaking down core concepts such as authentication, authorization, users, groups, roles, service principals, and managed identities. It concludes with a production-grade demonstration showing how to securely access a private Azure Blob Storage file from an Azure Linux Virtual Machine without hardcoding credentials.

## 1. Why Do We Need Identity and Access Management (IAM)?

When working with cloud platforms like Microsoft Azure, relying solely on a root or administrative user for daily operations creates massive security and auditing risks.

• The Problem of Broad Access: If every engineer, developer, and manager operates with full administrative privileges, accidental resource deletions or security breaches can go untracked and uncontained.
• The Need for Granular Control: Organizations need a systematic way to verify who is entering the cloud environment (Authentication) and exactly what actions they are permitted to perform once inside (Authorization).

## 2. Core Mental Model: The Office Building Analogy

To understand IAM, visualize a secure enterprise office building divided into multiple zones:

• Authentication (Who you are): Showing a valid employee ID card to pass through the main security gate. If you have no valid ID, you are blocked entirely.
• Authorization (What you are allowed to do): Even with a valid ID card, a software engineer is permitted in the lobby and cafeteria but denied entry into the secure server data center. Conversely, a network engineer is authorized to access all zones, including the data center.

## 3. Cloud Mapping: Users, Groups, and Roles in Azure

Translating this physical office model into Microsoft Azure:

• Authentication Service: Handled via Microsoft Entra ID (formerly Azure Active Directory / Azure AD).
• Authorization Mechanism: Handled via Azure Role-Based Access Control (RBAC), attaching predefined or custom roles to users and groups.

## 4. The Cloud Service for IAM: Microsoft Entra ID

Microsoft has rebranded its cloud directory services under the Microsoft Entra product family.

• Microsoft Entra ID: The specific cloud service responsible for managing identities, users, groups, and access policies (formerly known as Azure AD).
• Portal Navigation: Administrators manage identities by searching for Microsoft Entra ID in the Azure portal console, where they can manage users, assign group memberships, and configure role assignments.

## 5. Users vs. Groups: Administrative Scalability

• The Scaling Problem: If an organization has 100 developers and each is assigned permissions individually, modifying permissions (e.g., adding a new role) requires 100 manual updates.
• The Group-Based Solution: Administrators create distinct user accounts for auditability, but bundle them into Groups (e.g., Developer-Group).
  • When roles need updating, administrators apply the change once at the group level, and all group members instantly inherit the updated permissions.

## 6. Identity-to-Identity Communication: Service Principals & Managed Identities

Up to this point, IAM has focused on human users accessing Azure resources. However, cloud architectures frequently require Azure resources to communicate with each other (e.g., an Azure Virtual Machine needing to read files from Azure Blob Storage, or a Kubernetes cluster pulling images).

Azure Virtual Machine (Identity)
       |
       | requests access via Managed Identity token
       v
Azure Blob Storage Container (Protected Resource)

To enable resource-to-resource communication without embedding plain-text passwords or secret keys in application code, Azure provides two specialized identity constructs:

1. Service Principal: An application-specific security identity that requires manual secret rotation, certificate renewals, and credential maintenance by administrators.
2. Managed Identity: An identity automatically managed by Azure. Azure handles credential creation and automatic key rotation behind the scenes, making it the secure industry standard.

Managed Identity Variants

• System-Assigned Managed Identity: Tied directly to the lifecycle of a single Azure resource (e.g., a specific Virtual Machine). When the VM is deleted, the identity is automatically deleted.
• User-Assigned Managed Identity: Created as an independent standalone Azure resource that can be attached to multiple Azure resources simultaneously.

## 7. Practical Demonstration: Secure VM-to-Blob Storage Access

This demonstration walks through configuring a system-assigned managed identity on an Ubuntu Virtual Machine to securely read a private file from Azure Blob Storage without storing access keys on the disk.

Step 1: Create a Resource Group

Create a dedicated resource group to contain all lab resources for easy cleanup:

• Resource Group Name: managed-identity-poc
• Region: East US

Step 2: Create a Storage Account & Blob Container

1. Search for Storage Accounts in the Azure Portal and create a new account:
   • Name: managedpocstorage (must be globally unique)
   • Region: East US
2. Once deployed, navigate to the storage account, open Containers, and create a container named test.
3. Upload a sample file (e.g., index.html) into the test container.

Step 3: Create an Azure Linux Virtual Machine

1. Search for Virtual Machines and create an Ubuntu Linux VM:
   • Name: managed-demo-vm
   • Region: East US
   • Authentication: SSH Public Key or Username/Password (azure-user).
2. Ensure the VM and Storage Account reside in the same region (East US).

Step 4: Enable System-Assigned Managed Identity on the VM

1. Navigate to the managed-demo-vm resource in the Azure portal.
2. Under the Settings menu on the left, click Identity.
3. Select the System assigned tab, toggle Status to On, and click Save. This action automatically registers the VM as an identity within Microsoft Entra ID.

Step 5: Grant Storage Permissions via Azure RBAC

To authorize the VM's managed identity to read data from the storage account:

1. Navigate back to your Storage Account (managedpocstorage).
2. Click on Access Control (IAM) -> Add role assignment.
3. Select the Storage Blob Data Owner (or Storage Blob Data Reader) role and click Next.
4. Under Assign access to, choose Managed identity.
5. Click Select members, choose your subscription, select Virtual machine, and pick managed-demo-vm.
6. Click Review + assign.

Step 6: Validate Access via SSH and Shell Scripting

1. Connect to your VM via SSH using its Public IP address:
   BASH

   Copy

   ssh azure-user@<VM_PUBLIC_IP>
   

2. Update package repositories and install jq (a lightweight command-line JSON processor):
   BASH

   Copy

   sudo apt update
   sudo apt install -y jq
   

3. Fetch an Azure authentication access token locally from the VM's Azure Instance Metadata Service (IMDS) endpoint using the system-assigned managed identity:
   BASH

   Copy

   ACCESS_TOKEN=$(curl -s 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F' -H Metadata:true | jq -r .access_token)
   
   echo $ACCESS_TOKEN
   

4. Query the Azure Blob Storage REST API using the retrieved bearer token to download and print the contents of index.html:
   BASH

   Copy

   STORAGE_ACCOUNT="managedpocstorage"
   CONTAINER_NAME="test"
   BLOB_NAME="index.html"
   
   curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
        -H "x-ms-version: 2020-08-04" \
        "https://${STORAGE_ACCOUNT}.blob.core.windows.net/${CONTAINER_NAME}/${BLOB_NAME}"
   

   Result: The HTML file contents are successfully printed to the terminal without hardcoding any passwords, connection strings, or storage account keys in the shell script.

## 8. Production-Grade Debugging & Best Practices

• Identity vs. Token Propagation: If permission changes do not take effect immediately after role assignment, wait a few minutes for Azure's global RBAC cache to synchronize across control planes.
• Principle of Least Privilege: In production environments, avoid assigning broad roles like Owner or Contributor. Instead, assign granular roles such as Storage Blob Data Reader so that compromised virtual machines cannot alter or delete storage containers.
• Cleanup: Always delete the parent resource group (managed-identity-poc) when finished testing to prevent unexpected Azure billing charges.

## Summary and Key Takeaways

• IAM Foundation: Identity and Access Management relies on two distinct pillars: Authentication (verifying identity) and Authorization (determining permissions).
• Real-World Analogy: Authentication acts like checking an employee ID badge at the front gate, while authorization acts like restricting server room access to network engineers only.
• Microsoft Entra ID: The core Azure directory service used to manage human identities, user accounts, and security groups.
• Groups for Scalability: Instead of assigning roles to thousands of individual users manually, group users by department to simplify permission management.
• Roles: Define granular permissions (e.g., read-only, VM creator) assigned to users and groups via Azure RBAC.
• Resource-to-Resource Communication: When Azure resources need to communicate securely without embedded passwords, administrators use Service Principals or Managed Identities.
• Managed Identities Advantage: Azure automatically handles secret creation and key rotation for managed identities, making them far more secure than static service principal credentials.
• Metadata Service (IMDS): Azure VMs equipped with a managed identity can fetch OAuth2 bearer tokens locally via http://169.254.169.254/ to authenticate against Azure APIs securely.