Sequence 7 — Microsoft Entra ID, RBAC & Anonymous Access

Prerequisites: Sequence 6 (the authorization model — Access Keys & SAS). · What you'll be able to do: explain how Microsoft Entra ID + OAuth 2.0 authorize data requests with no secret in code; tell apart management-plane roles from data-plane RBAC roles and assign the right one at the right scope; disable Shared Key to enforce Entra; lock down anonymous public access org-wide. · Est. time: ~14 min.

1. Why Microsoft Entra ID for data access

In Sequence 6 you saw Shared Key (account keys) and SAS — both rely on a secret that must be stored, rotated, and protected. Microsoft Entra ID is the third and recommended way to authorize requests to Blob, Queue, and Table data. Its advantage: no secret lives in your code. Identities are managed centrally, access is granted through Azure role-based access control (Azure RBAC), and you get full auditing.

Authorization with Entra is a two-step process:

1. Authenticate — the security principal proves its identity to Microsoft Entra ID, which returns a short-lived OAuth 2.0 access token.
2. Authorize — the token is sent with each request to the storage service, which checks whether the principal has an RBAC role granting the requested operation at the relevant scope.

Key facts to memorize:

• Supported on all general-purpose v2 and Blob storage accounts, in all public regions and national clouds.
• Only accounts using the Azure Resource Manager (ARM) deployment model support Entra authorization (not the legacy "classic" model).
• In code, acquire the token with the Azure Identity client library (the DefaultAzureCredential class is the simple, recommended path — same code works locally and in Azure). MSAL is for advanced scenarios.
• For apps running inside an Azure resource (VM, scale set, Functions), use a managed identity so there is no credential at all in the app.

Azure Files data does not use this token model for SMB access — it uses identity-based authentication over Kerberos, covered in Sequence 9. SAS is Sequence 6.

2. The crucial split: management plane vs. data plane

This is the single most tested concept in this episode. Azure has two planes, and a role on one does not automatically grant the other.

[!IMPORTANT] Owner and Contributor can manage the account but do NOT grant access to blob/queue/table data via Microsoft Entra ID. Only roles explicitly defined for data access let a principal touch the data through Entra.

The dangerous subtlety: a management role that includes the Microsoft.Storage/storageAccounts/listKeys/action permission (Owner, Contributor, Storage Account Contributor all have it) lets the holder fetch the account keys and then reach data via Shared Key — a back door that bypasses data-plane RBAC entirely. This is exactly why disabling Shared Key (Section 5) matters, and why the Azure portal picks its auth method based on whether you hold listKeys (Section 6).

3. Built-in data-plane roles

Azure Storage ships built-in data roles per service. The blob trio is the one to know cold:

Parallel families exist for the other services (same Reader/Contributor pattern):

You can also build custom roles for granular needs, and refine access with Azure attribute-based access control (Azure ABAC) — adding conditions on a role assignment (e.g., only blobs with a given tag/path). ABAC for blobs is (Preview).

4. Choosing the scope, then assigning the role

A role assignment = who (principal) + what (role) + where (scope). A security principal can be a user, group, application service principal, or managed identity.

Scope is inherited downward — a role set at a broad scope applies to everything beneath it. Always grant the narrowest scope that works (least privilege).

[!NOTE] Creating a storage account gives you no data permissions automatically — you must explicitly assign yourself a data role.

Assign via the portal: open the storage account (or a container) → Access Control (IAM) → Add → Add role assignment → pick a data role (e.g., Storage Blob Data Contributor) → select the member → Review + assign. You need a role with Microsoft.Authorization/roleAssignments/write (e.g., Owner or User Access Administrator) at that scope or higher.

Azure CLI — scope a container to honor least privilege:

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee user@contoso.com \
  --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>/blobServices/default/containers/<container>"

Assigning to a managed identity or service principal (use the object ID + principal type, which avoids ambiguity):

az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee-object-id "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb" \
  --assignee-principal-type "ServicePrincipal" \
  --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>"

Az PowerShell equivalent:

New-AzRoleAssignment -SignInName user@contoso.com `
  -RoleDefinitionName "Storage Blob Data Contributor" `
  -Scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>/blobServices/default/containers/<container>"

Propagation delay — exam favorite: role changes can take up to ~10 minutes to take effect (the source page elsewhere cites up to 30 minutes as a worst case — allow time before troubleshooting). At management-group scope, data-action permissions can rarely take up to 12 hours — so do not use management-group scope for time-sensitive grant/revoke (e.g., PIM). If you set allow permissions but still get AuthorizationPermissionMismatch, first wait for replication, then check for deny assignments and read-only resource locks (a read-only lock blocks new role assignments scoped to the account/container).

5. Forcing Entra: disable Shared Key

Because anyone who can read the account keys (via listKeys) can bypass data RBAC through Shared Key, the hardening step is to disable Shared Key authorization on the account. Then every request to Blob/Queue/Table/Files must use Microsoft Entra ID (SAS signed with the account key also stops working; user-delegation SAS still works because it is Entra-backed — see Seq 6).

az storage account update \
  --name <account> --resource-group <rg> \
  --allow-shared-key-access false

Before flipping this, confirm nothing depends on keys/SAS, and ensure principals already hold the right data roles — otherwise you lock everyone out.

6. How the portal chooses Entra vs. key

When you browse data in the Azure portal, it decides the auth method for you:

• If your role includes Microsoft.Storage/storageAccounts/listkeys/action → the portal uses the account key (Shared Key).
• If not → it falls back to your Microsoft Entra account.

To browse data with your Entra identity, you need both:

1. a data role (e.g., Storage Blob Data Reader/Contributor), and
2. the ARM management-plane Reader role (or higher) scoped to the account — so you can navigate to the account in the portal. Data roles grant data access but not the ability to see the account resource in the portal tree.

7. Anonymous (public) read access

Separate from all of the above: blobs can optionally be served to anyone, with no credential — useful for public websites/assets, but a security risk that is the source of many data leaks. Anonymous access is controlled at two levels, and both must allow it for public reads to work:

Defaults & guidance:

• By default anonymous access is never permitted — every request must be authorized unless you explicitly opt in.
• Microsoft recommends disabling anonymous access on all accounts. New accounts default AllowBlobPublicAccess appropriately; the safe posture is False.
• Setting the account switch to False is the org-wide remediation — it immediately overrides any per-container setting.

Disable anonymous access on an account (remediation):

az storage account update \
  --name <account> --resource-group <rg> \
  --allow-blob-public-access false

If you genuinely need public content: isolate it — put those containers in a dedicated storage account reserved for anonymous access, and keep AllowBlobPublicAccess = False everywhere else. Enforce this at scale with Azure Policy (deny accounts where public access is enabled).

Key takeaways

• Entra = no secret in code. Two steps: authenticate → OAuth 2.0 token → authorize via RBAC. Use managed identity inside Azure; DefaultAzureCredential in code.
• "Owner ≠ data owner." Management roles (Owner/Contributor) manage the account but grant no data access via Entra. You need a Storage Data role.
• Blob trio mnemonic — R-C-O = Read / Read+Write+Delete / +ACLs(ADLS): Reader → Contributor → Owner.
• Scope inherits downward; grant the narrowest. MG → Sub → RG → Account → Container.
• Wait ~10 min for role propagation (worst case longer; up to 12 h at MG scope). AuthorizationPermissionMismatch usually means wait, or check deny assignments / locks.
• listKeys is the back door — disable Shared Key (--allow-shared-key-access false) to force Entra.
• Anonymous access = two gates: account AllowBlobPublicAccess AND container level (Private / Blob / Container). Account False wins. Default-deny; isolate public content in its own account.

Exercises

1. (Recall) A developer is assigned Contributor on a storage account and is surprised they can't read blobs via their Entra identity from an app using DefaultAzureCredential. Why, and what role fixes it?
2. (Recall) List the three core blob data roles from least to most privilege, and say what extra capability the most privileged one adds.
3. (Applied) Write the Azure CLI command to grant a managed identity (object ID 1111...) read-only data access to a single container named images.
4. (Scenario) You enabled the correct data role 3 minutes ago but still get AuthorizationPermissionMismatch. Give two distinct causes and how to resolve each.
5. (Scenario) A marketing team needs one container of public images, but security mandates no anonymous access anywhere. Describe the architecture you'd recommend.
6. (Applied) Your org wants to guarantee that no account in a subscription can ever serve data anonymously. Name two complementary controls and the exact property each relies on.

Coming up next

Sequence 8 — Network Security: Firewalls, VNets & Private Endpoints — restricting where requests may originate, the network-layer complement to the identity controls you just learned.