Azure Role-Based Access Control

Who, what role, at which scope

A role assignment has three parts: a security principal (user, group, service principal or managed identity), a role definition (a list of allowed actions) and a scope (management group, subscription, resource group or single resource). Assignments inherit downwards: Reader on a subscription means Reader on every resource group inside it. Four built-in roles cover the basics: Owner (full access including granting access), Contributor (full management but cannot grant access), Reader (view only) and User Access Administrator (manage access only). Many services add data-plane roles, such as Storage Blob Data Reader or Key Vault Secrets User, because managing a storage account and reading its blobs are different permissions. If no built-in role fits, you can write a custom role.

A least-privilege assignment

Give an app read access to blobs in one storage account, nothing more.

SCOPE=$(az storage account show -n stshopdev123 -g rg-shop-dev-cin --query id -o tsv)

az role assignment create \
  --assignee <principal-object-id> \
  --role "Storage Blob Data Reader" \
  --scope "$SCOPE"

az role assignment list --scope "$SCOPE" -o table

Key cards with floors

A role is what a key card opens, the scope is which floor it works on. Giving everyone the master key to the whole building (Owner on the subscription) is convenient until something goes missing.

Quick check: A CI pipeline must deploy resources into one resource group but must never grant access to others. Which built-in role at which scope fits best?

• Owner on the subscription
• Contributor on that resource group
• User Access Administrator on the resource group
• Reader on the subscription