Stage 5 · Platform

Azure Foundations

Azure AD & RBAC

Entra ID, service principals, managed identities, and RBAC roles for secure access.

8 min readAzure Cloud EngineeringPlatform

Microsoft Entra ID

Microsoft Entra ID (formerly Azure Active Directory) is Azure's identity and access management service. It handles authentication (who are you?) and authorization (what can you do?) for all Azure resources and services.

Entra ID is distinct from on-premises Active Directory. It is a cloud-native, REST-based identity service. Every Azure subscription trusts exactly one Entra ID tenant for identity services.

Tenant = Entra ID instance

A tenant is a dedicated Entra ID instance representing an organization. Each Azure subscription is associated with exactly one tenant. Multiple subscriptions can share a tenant.

The RBAC Model

Azure Role-Based Access Control (RBAC) is the authorization system used to manage who has access to Azure resources and what they can do with those resources. RBAC is built on a model of Role Assignments.

RBAC role assignment structure


# Every role assignment has three components:
# 1. Security Principal (who) — user, group, service principal, managed identity
# 2. Role Definition (what) — a collection of permissions (e.g., Contributor)
# 3. Scope (where) — subscription, resource group, or resource

# List all role assignments for a subscription
az role assignment list \
  --scope "/subscriptions/{subscription-id}" \
  --query "[].{principal:principalName, role:roleDefinitionName, scope:scope}" \
  --output table

RBAC is additive. If a user has Contributor at the subscription level and Reader at a resource group, they effectively have Contributor everywhere.

Built-in Roles

Azure provides over 100 built-in roles. The most commonly used are Owner, Contributor, Reader, and User Access Administrator. Each role grants a specific set of permissions.

Role	Can Manage Resources	Can Manage Access	Typical Use
Owner	Yes	Yes	Subscription admins
Contributor	Yes	No	Developers deploying resources
Reader	View only	No	Auditors, monitoring tools
User Access Administrator	No	Yes	IAM-only management

List available roles


# Find roles related to storage
az role definition list --query "[?contains(roleName, 'Storage')].{name:roleName, type:permissions[0].actions}" --output table

# Get details of a specific role
az role definition show --name "Contributor" --query "{name:roleName, actions:permissions[0].actions}" --output json

You can scope roles to specific resource types. For example, the 'Storage Blob Data Contributor' role only grants access to blob storage, not all storage.

Service Principals

A service principal is an identity created for use by applications, automation tools, or CI/CD pipelines. It is the recommended way to authenticate non-interactive workloads in Azure.

Create a service principal


# Create a service principal with Contributor role on a subscription
az ad sp create-for-rbac \
  --name "sp-terraform-prod" \
  --role "Contributor" \
  --scopes "/subscriptions/{subscription-id}" \
  --sdk-auth

# The output contains:
# - clientId (the App ID)
# - clientSecret (the password — save it immediately)
# - tenantId
# - subscriptionId

The --sdk-auth flag outputs JSON suitable for Terraform's Azure provider. For newer approaches, use federated credentials to avoid storing secrets entirely.

Avoid long-lived secrets

Service principal secrets expire. Use federated credentials (OIDC) for CI/CD pipelines, or rotate secrets regularly. Microsoft recommends federated credentials as the primary authentication method.

Custom Roles

When built-in roles do not match your access requirements, you can create custom roles. Custom roles define a specific set of actions, not-actions, data actions, and not-data actions.

Create a custom role


az role definition create --role-definition '{
  "Name": "Storage Reader and Key Vault User",
  "Description": "Read storage accounts and read secrets from Key Vault",
  "Actions": [
    "Microsoft.Storage/storageAccounts/read",
    "Microsoft.KeyVault/vaults/secrets/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}"
  ]
}'

Custom roles can only be assigned at the subscription scope or below. They cannot be assigned at the management group level without explicit scoping.

Role Assignments in Practice

The most common pattern is to assign roles at the resource group scope. This keeps permissions organized — everything in the resource group inherits the same access level.

Practical role assignment patterns


# Assign Contributor to a service principal on a specific resource group
az role assignment create \
  --assignee "00000000-0000-0000-0000-000000000000" \
  --role "Contributor" \
  --resource-group "rg-payments-prod"

# Assign a custom role to a managed identity
az role assignment create \
  --assignee "mi-aks-payments" \
  --role "Storage Reader and Key Vault User" \
  --resource-group "rg-payments-prod"

# List all role assignments for a user
az role assignment list --assignee "user@contoso.com" --output table

Use the principle of least privilege. Assign the narrowest role at the smallest scope necessary. Start with Reader and add permissions as needed.

Deny assignments override allow

In Azure RBAC, deny assignments always take precedence over role assignments. However, you cannot create custom deny assignments — only Azure Blueprints and managed apps can create them.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.