Identity and Access

First PublishedFeb 17, 2026ByAtif Alam

Identity in Azure is handled by Microsoft Entra ID (formerly Azure Active Directory / Azure AD). It’s different from AWS IAM — Entra ID is a full identity provider (SSO, MFA, directory services) while Azure RBAC handles authorization on resources.

Core Concepts

┌──────────────────────────────────────────────┐
│  Entra ID Tenant                              │
│  (your organization's identity directory)     │
│                                               │
│  ┌──────────┐  ┌──────────┐  ┌────────────┐  │
│  │  Users    │  │  Groups  │  │  App        │  │
│  │ (people) │  │ (teams)  │  │ Registrations│ │
│  └────┬─────┘  └────┬─────┘  └──────┬─────┘  │
│       └──────┬───────┘               │        │
│              ▼                       ▼        │
│    ┌──────────────────────────────────────┐   │
│    │  Azure RBAC                          │   │
│    │  (role assignments on resources)     │   │
│    │  "Reader on subscription X"          │   │
│    │  "Contributor on resource group Y"   │   │
│    └──────────────────────────────────────┘   │
└──────────────────────────────────────────────┘

Concept	What It Is
Tenant	An Entra ID instance representing your organization. Contains all users, groups, and app registrations.
User	A person or account in the directory. Can sign in with email/password, SSO, or MFA.
Group	A collection of users. Assign roles to groups instead of individual users.
Service principal	An identity for an application or service (like an AWS IAM role for an app).
Managed identity	An Azure-managed service principal for Azure resources — no credentials to manage.
App registration	Registers an application with Entra ID for authentication (OAuth2, OIDC).

Entra ID vs AWS IAM

	Azure (Entra ID + RBAC)	AWS (IAM)
Identity	Entra ID (full directory: SSO, MFA, federation)	IAM users (basic, no directory)
Authorization	Azure RBAC (role assignments on scopes)	IAM policies (JSON, attached to identities)
Service identity	Managed identity / service principal	IAM role (instance profile)
Groups	Entra ID groups	IAM groups
SSO	Built-in (SAML, OIDC, WS-Fed)	External (Okta, etc. via federation)
MFA	Built-in	Built-in (simpler)

Azure RBAC (Role-Based Access Control)

RBAC controls what users and services can do with Azure resources.

How It Works

A role assignment has three parts:

WHO (security principal) + WHAT (role) + WHERE (scope) = access

Part	Examples
Security principal	User, group, service principal, managed identity
Role	Reader, Contributor, Owner, custom roles
Scope	Management group, subscription, resource group, or single resource

Built-In Roles

Role	Permissions
Owner	Full access + can assign roles to others
Contributor	Full access except role assignments
Reader	Read-only access
User Access Administrator	Manage role assignments only

There are also hundreds of service-specific roles:

Role	Scope
Virtual Machine Contributor	Manage VMs but not access the network or storage
Storage Blob Data Reader	Read blob data (not the storage account itself)
AKS Cluster Admin	Full access to AKS clusters
Key Vault Secrets User	Read secrets from Key Vault
SQL DB Contributor	Manage SQL databases

Assigning Roles

# Assign "Contributor" to a user on a resource group
az role assignment create \
  --assignee [email protected] \
  --role Contributor \
  --resource-group myapp-prod-rg

# Assign "Reader" to a group on a subscription
az role assignment create \
  --assignee-object-id <group-object-id> \
  --role Reader \
  --scope /subscriptions/<subscription-id>

# List role assignments
az role assignment list --resource-group myapp-prod-rg --output table

Scope Hierarchy

Roles assigned at a higher scope are inherited by lower scopes:

Management Group  ──►  Subscription  ──►  Resource Group  ──►  Resource
(broadest)                                                    (narrowest)

A “Contributor” role on a subscription applies to all resource groups and resources within it.

Custom Roles

az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but not create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

Service Principals

A service principal is an identity for an application, script, or CI/CD pipeline. It has its own credentials (secret or certificate) and RBAC role assignments.

Creating a Service Principal

# Create with a secret (returns appId, password, tenant)
az ad sp create-for-rbac \
  --name "myapp-cicd" \
  --role Contributor \
  --scopes /subscriptions/<sub-id>/resourceGroups/myapp-prod-rg

# Output:
# {
#   "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
#   "displayName": "myapp-cicd",
#   "password": "generated-secret",
#   "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# }

Using a Service Principal

# Login as the service principal
az login --service-principal \
  --username <appId> \
  --password <password> \
  --tenant <tenant>

In CI/CD, store these credentials as pipeline secrets (or better, use federated credentials with OIDC — no secrets to manage).

Federated Credentials (OIDC)

Like AWS OIDC for GitHub Actions — no secrets needed:

# Create federated credential for GitHub Actions
az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name": "github-main",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:myorg/myrepo:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"]
  }'

Managed Identities

Managed identities are the recommended way for Azure resources to authenticate to other Azure services — no credentials to store or rotate.

Types

Type	What It Is	Use Case
System-assigned	Tied to one resource. Created and deleted with the resource.	VM, App Service, Function, AKS pod
User-assigned	Standalone identity. Can be shared across resources.	Multiple VMs/services needing the same access

Enabling a Managed Identity

# Enable system-assigned identity on a VM
az vm identity assign --resource-group myapp-rg --name my-vm

# Enable on an App Service
az webapp identity assign --resource-group myapp-rg --name my-webapp

Granting Access

# Get the managed identity's principal ID
PRINCIPAL_ID=$(az vm identity show --resource-group myapp-rg --name my-vm --query principalId -o tsv)

# Grant it "Storage Blob Data Reader" on a storage account
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub>/resourceGroups/myapp-rg/providers/Microsoft.Storage/storageAccounts/mystorage

Using in Code

The Azure SDKs automatically detect managed identities — no credentials in code:

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# DefaultAzureCredential automatically uses managed identity when running on Azure
credential = DefaultAzureCredential()
blob_service = BlobServiceClient(
    account_url="https://mystorage.blob.core.windows.net",
    credential=credential
)

DefaultAzureCredential tries multiple methods in order: environment variables → managed identity → Azure CLI → Visual Studio Code → Interactive browser. It works both locally (CLI) and in production (managed identity).

Conditional Access

Conditional access policies add context-aware rules to authentication:

User attempts sign-in
    │
    ▼
Entra ID evaluates conditions:
  ├── User/group membership
  ├── Location (IP range, country)
  ├── Device state (compliant, managed)
  ├── Application being accessed
  └── Risk level (sign-in risk, user risk)
    │
    ▼
Apply controls:
  ├── Allow (with MFA)
  ├── Block
  ├── Require compliant device
  └── Require approved app

Examples:

• Require MFA for all users accessing Azure portal.
• Block sign-ins from countries where you don’t operate.
• Require a compliant device for accessing sensitive apps.
• Force password change when sign-in risk is high.

Azure Key Vault (Secrets)

Key Vault is Azure’s secrets management service (like AWS Secrets Manager + KMS):

# Create a Key Vault
az keyvault create --name myapp-vault --resource-group myapp-rg --location eastus

# Store a secret
az keyvault secret set --vault-name myapp-vault --name db-password --value 'S3cure!Pass'

# Retrieve a secret
az keyvault secret show --vault-name myapp-vault --name db-password --query value -o tsv

Key Vault stores three types of objects:

Type	What It Stores
Secrets	Connection strings, passwords, API keys
Keys	Encryption keys (RSA, EC) — can be HSM-backed
Certificates	TLS/SSL certificates with auto-renewal

Access is controlled via RBAC or vault access policies. Use managed identities to access Key Vault from your applications.

Best Practices

Practice	Why
Use groups for role assignments	Easier to manage than per-user assignments
Use managed identities for Azure resources	No credentials to manage or rotate
Use service principals with OIDC for CI/CD	No secrets in pipelines
Apply least privilege	Use narrow roles (e.g. “Storage Blob Data Reader” not “Contributor”)
Assign roles at the narrowest scope	Resource group or resource level, not subscription
Enable MFA for all users	Protects against credential theft
Use conditional access	Context-aware security (location, device, risk)
Store secrets in Key Vault	Never in code, config files, or environment variables
Review access with access reviews	Periodic review of who has what access

Key Takeaways

• Entra ID (Azure AD) is the identity provider — users, groups, SSO, MFA. Azure RBAC controls what identities can do on resources.
• RBAC = WHO (principal) + WHAT (role) + WHERE (scope). Roles inherit down the scope hierarchy.
• Managed identities are the preferred way for Azure resources to authenticate — no secrets needed.
• Service principals are for external applications and CI/CD. Use federated credentials (OIDC) to avoid storing secrets.
• Key Vault stores secrets, encryption keys, and certificates. Access it via managed identity.
• Conditional access adds context-aware rules to sign-in (MFA, device compliance, location).