Microsoft Entra ID, Azure RBAC, Service Principals, and Managed Identities

Microsoft Entra ID is Azure's identity system. Authentication proves an identity; authorization decides what it may do. Azure role-based access control combines a security principal, role definition, and scope. Managed identity gives an Azure workload an Entra identity without storing a client secret in application configuration.

Lab: 35 minutes · Cost: no separate charge for basic RBAC or managed identity · Risk: access changes can lock people out or grant excessive privilege; use a learning scope.

What identities exist in Azure?

An app registration describes an application in its home tenant. A service principal is that application's local identity instance in a tenant. Do not call every service principal a managed identity; managed identities are a specialized, Azure-operated form.

How does Azure RBAC work?

Built-in roles include Reader, Contributor, Owner, and specialized data roles. Contributor can manage resources but cannot grant Azure RBAC access. Owner can manage resources and access. Data-plane actions often need a data role such as Storage Blob Data Contributor; management Contributor alone may not read blob content.

How do you inspect and assign Azure RBAC access?

Ways to build

Choose the Azure tool you want to use. The underlying resource stays the same.

Azure portalAzure CLIAzure PowerShell

Azure portal

Open a subscription, resource group, or resource → Access control (IAM).

• Check access shows assignments for a principal.
• Role assignments lists current assignments.
• Add → Add role assignment starts the guided flow.

Assign groups instead of many individuals. Choose the narrowest practical scope. Use privileged identity management and time-bound activation in eligible enterprise tenants.

Azure CLI

Assume an existing group and a learning resource group:

bash

WrapCopy

AZURE_RG="rg-northstar-dev-001" AZURE_SCOPE="$(az group show --name "$AZURE_RG" --query id --output tsv)" ENTRA_GROUP_ID="REPLACE_WITH_GROUP_OBJECT_ID" az role assignment create \ --assignee-object-id "$ENTRA_GROUP_ID" \ --assignee-principal-type Group \ --role Reader \ --scope "$AZURE_SCOPE"

Using object IDs avoids a second lookup and name ambiguity.

Azure PowerShell

powershell

WrapCopy

$GroupObjectId = "REPLACE_WITH_GROUP_OBJECT_ID" $Scope = (Get-AzResourceGroup -Name "rg-northstar-dev-001").ResourceId New-AzRoleAssignment -ObjectId $GroupObjectId -RoleDefinitionName "Reader" -Scope $Scope

RBAC changes can take minutes to propagate. Do not respond by granting a broader role immediately.

How do you enable a managed identity?

Many resources expose Identity → System assigned → On in the portal. CLI examples are resource-specific. For a web app:

Grant only the required data role at the target resource:

Application code then uses the Azure Identity library's default credential chain. It receives a short-lived token; it does not need the vault secret in configuration.

How do Bicep and Terraform express identity and access?

Bicep attaches an identity to a supported resource:

Role assignments require a deterministic GUID name based on scope, principal, and role; use a documented built-in role definition ID. In Terraform, use the resource's identity block and azurerm_role_assignment. Do not use role names that vary by localization when a stable ID is available.

When should you use a service principal?

Use it for an external automation system that cannot have managed identity. Prefer OpenID Connect workload identity federation over a client secret. If a legacy secret is unavoidable, store it in an approved secret manager, rotate it, restrict scope, monitor its use, and set an expiry.

Never create an application identity with Owner at subscription scope because a deployment pipeline “might need it.” Discover required actions from the deployment and create a custom role only when built-in roles are too broad or too narrow.

Verify and remove access

Remove the exact assignment when finished:

Common mistakes

• Confusing Azure RBAC with Entra directory roles.
• Giving Contributor when only a data-plane role is needed.
• Assigning users individually instead of groups.
• Storing a client secret where managed identity works.
• Ignoring inherited assignments at parent scopes.
• Using a user-assigned identity across workloads that need different permissions.

Official references

• Microsoft Entra ID documentation
• Azure RBAC overview
• Managed identities overview
• Workload identity federation