Who may touch the till?
Sita hires Asha to look after the website and Bikash to run the database. Asha should be able to restart web servers but not read customer data; Bikash should manage the database but not the website. Handing both of them the subscription Owner's password would be a disaster waiting to happen.
Azure role-based access control (RBAC) answers three questions for every request ARM receives: who is asking (a security principal — a user, group, service principal or managed identity), what they want to do (an action like Microsoft.Compute/virtualMachines/restart/action), and where (a scope). Today you'll build the decision ARM makes.
Roles, scopes and assignments
A role definition is a named list of permissions. Its actions say what it allows, with * as a wildcard, and its notActions carve exceptions out of those actions. A role assignment binds a role to a principal at a scope: "Asha · Contributor · the web resource group". Assignments are inherited, so a role at the subscription applies to every group and resource in it.
- Owner: everything, including granting access to others.
- Contributor: everything except managing access (Microsoft.Authorization/*/Write and Delete are NotActions).
- Reader: */read — look, don't touch.
- User Access Administrator: manage who has access, but not the resources themselves.
- Many service roles too, like Virtual Machine Contributor: manage VMs but not their network or storage.
Contributor: {
actions: ["*"],
notActions: ["Microsoft.Authorization/*/Write", ...],
}Keys on a ring: Each role assignment is a key. Asha's ring has a Reader key for the whole building and a Contributor key for the web room. A door opens if any one key fits — extra keys never lock a door.