Azure access in one picture: Entra ID, RBAC and managed identities

Most Azure access problems are a confusion between three things that look alike: Microsoft Entra ID, which decides who you are; Azure role-based access control (RBAC), which decides what you may do to which resources; and managed identities, which let your apps and services take part without a password or key. Each has its own roles, its own scopes and its own delays, and a setting in one is often blamed on another. This is the start of our Identity & security column: one picture of how the three fit, then the distinctions that explain nearly every "I have the role and it still says no".

Who you are: Entra ID

Every call to Azure carries a token from a Microsoft Entra tenant. The token names a security principal: a user, a group, a service principal (an app registration's identity in your tenant) or a managed identity (a service principal Azure creates and looks after for a resource). The principal's object ID is what role assignments point at; display names aren't unique and renames don't matter.

Entra ID also has its own roles, such as Global Administrator, User Administrator and Application Administrator. They govern the directory: users, groups, app registrations, licences, domains. They don't give access to Azure resources. A Global Administrator who can't see a subscription isn't misconfigured; that's the design. The exception is deliberate: a Global Administrator can elevate access once to become User Access Administrator on every subscription in the tenant, to recover a subscription nobody can reach any more, and should switch it off afterwards.

What you may do: Azure RBAC

An Azure role assignment is three things together: a role definition (a list of allowed actions), a principal, and a scope. Scopes nest, and assignments inherit downwards:

Management group
  └─ Subscription
       └─ Resource group
            └─ Resource (a storage account, a vault, a function app)

Reader at the subscription means Reader on every resource group and resource beneath it. Assign at the narrowest scope that does the job, and prefer groups as the principal for people so access follows the team rather than the person.

The five roles everyone meets:

A deny assignment blocks an action even when a role allows it; you meet them through Azure Blueprints, deployment stacks and managed applications, not something you normally create by hand. Conditions (attribute-based access control) narrow an assignment, for instance "may assign only these roles, and only to these kinds of principal".

Azure's classic subscription administrator roles are gone: retired on 31 August 2024, with any remaining Co-Administrators and Service Administrators converted to Owner from December 2025 and the roles fully removed in May 2026. If a runbook still talks about them, it's older than it looks.

Two kinds of role, and two planes

The first distinction is the one above: Entra roles for the directory, Azure roles for resources. The second trips up far more people.

Owner and Contributor have a wildcard in Actions and nothing in DataActions. They can create a storage account, delete it, and change its firewall; they cannot read a blob in it. For that you need a data role: Storage Blob Data Reader, Key Vault Secrets User, Cosmos DB Built-in Data Reader, Foundry User. The separation is deliberate, so that a role with * can't quietly read every byte in the subscription. The old loophole is the account key: a control-plane role that includes listKeys can fetch the storage account's keys and bypass RBAC entirely, which is why turning off shared-key access is on every hardening list.

A corollary: a lock that stops a database being deleted doesn't stop a query from deleting its rows. Locks, Policy and the activity log are control-plane features.

Your code: managed identities

A person signs in; an app needs a credential. Three choices, in order of preference:

1. A managed identity when the code runs on Azure (App Service, Functions, Container Apps, AKS, VMs, Logic Apps, Data Factory and more). Azure creates a service principal, rotates its credential, and your code asks the platform for a token: no secret exists for you to leak. System-assigned identities live and die with one resource; user-assigned identities are resources of their own, shared across several resources, with role assignments made in advance of deployment. Microsoft recommends user-assigned for most cases. Our managed identities guide goes through the choice, the SDK and the errors.
2. Workload identity federation when the code runs elsewhere (GitHub Actions, Azure DevOps, another cloud): the other platform's own token is exchanged for an Entra token against a federated credential you configure, again without a secret.
3. A service principal with a secret or certificate, the old way, when neither of the above fits. Secrets expire and leak; certificates are the better of the two.

Whichever you choose, it's still just a principal: it gets Azure roles at scopes like anyone else, and it meets the same two planes.

The five places access goes wrong

One habit prevents most of the rest: give access to groups and identities at the smallest scope, with the data role the task needs, and check it with the account that will actually do the work, not with your own Owner account, which hides the planes problem until production.

Sources

• Azure roles, Microsoft Entra roles, and classic subscription administrator roles, Microsoft Learn
• Understand Azure role definitions, Microsoft Learn (control and data actions)
• Azure control plane and data plane, Microsoft Learn
• What is managed identities for Azure resources?, Microsoft Learn
• Managed identity best practice recommendations, Microsoft Learn
• Troubleshoot Azure RBAC, Microsoft Learn (propagation and caching)