TopolearnRBAC decides who can do what to every resource; getting it right is the core of Azure security.
Azure role-based access control works through role assignments, each with three parts:
- Security principal: a user, group, service principal or managed identity.
- Role definition: a list of allowed
Actions(control plane, e.g.Microsoft.Storage/storageAccounts/write) andDataActions(data plane, e.g. reading blobs). - Scope: management group, subscription, resource group or single resource.
Assignments are additive and inherited downward; the effective permission is the union of all roles that apply. Explicit deny assignments exist but are created by the platform (for example by deployment stacks or managed apps), not by you directly.
Built-in roles to know: Owner (everything, including granting access), Contributor (everything except granting access), Reader, User Access Administrator, and many service roles such as Storage Blob Data Reader or Key Vault Secrets User.
The control plane versus data plane split matters: Contributor on a storage account lets you manage it, but reading blobs with your Entra identity needs a data role such as Storage Blob Data Reader.
Least privilege in practice: assign roles to groups, at the narrowest useful scope, prefer specific service roles over Contributor, and use Privileged Identity Management for just-in-time elevation of powerful roles. New assignments can take several minutes to take effect.
Example
GROUP_ID=$(az ad group show --group orders-devs --query id -o tsv)
RG_ID=$(az group show -n rg-orders-dev --query id -o tsv)
# Contributor on one resource group only
az role assignment create --assignee-object-id "$GROUP_ID" \
--assignee-principal-type Group --role Contributor --scope "$RG_ID"
# Data-plane access to blobs in one storage account
az role assignment create --assignee-object-id "$GROUP_ID" \
--assignee-principal-type Group --role "Storage Blob Data Reader" \
--scope "$RG_ID/providers/Microsoft.Storage/storageAccounts/stordersdev"
az role assignment list --scope "$RG_ID" --query "[].{who:principalName, role:roleDefinitionName}" -o tableRemember
- Role assignment = principal + role + scope
- Permissions are additive and inherit to child scopes
- Management rights (Actions) and data rights (DataActions) are separate
- Owner can grant access; Contributor cannot
Watch out for
- Giving a workload Contributor on a subscription when it only needs to read secrets from one Key Vault.