Owner vs Contributor vs Reader: Azure RBAC without the guesswork
There are hundreds of built-in Azure roles, but three cover most of what you do — and the difference between two of them is the single most common access mistake in the cloud. Here is the model, and the trap.
Azure role-based access control (RBAC) is how you answer "who can do what, where." It sounds like it should require a spreadsheet, but the everyday reality runs on three fundamental roles: Owner, Contributor, and Reader. Learn exactly what separates them and you can grant access confidently — and stop handing out Owner because you were not sure.
The three roles, in Microsoft's own words
| Role | What it grants | Can assign roles? |
|---|---|---|
| Owner | Full access to manage all resources | Yes — and can manage others' access |
| Contributor | Full access to manage all resources | No |
| Reader | View all resources; make no changes | No |
Microsoft's definitions are precise. Owner "grants full access to manage all resources, including the ability to assign roles in Azure RBAC." Contributor "grants full access to manage all resources, but does not allow you to assign roles." Reader lets you "view all resources, but does not allow you to make any changes." Two of those descriptions are almost identical — and that near-identical pair is where the trap lives.
The one difference that matters
Owner and Contributor can both do essentially everything to the resources — create, change, delete VMs, databases, networks, all of it. The single distinction is access management. Owner can grant and revoke other people's access; Contributor cannot. Contributor can build the entire environment but cannot hand out a single role.
That gap is the whole point, and it is the security control people accidentally throw away. If a team needs to deploy and manage workloads, they need Contributor — not Owner. Giving them Owner "to be safe" hands them the power to grant themselves and anyone else more access, quietly, forever. The instinct that Owner is the helpful, generous choice is exactly backwards: Owner is the role you give almost no one.
Contributor builds everything and grants nothing. That gap is a feature, not a limitation.
What if someone genuinely needs to manage access but should not touch the resources? That is a specific built-in role — User Access Administrator — which grants role assignment and nothing more. Splitting "who can change things" from "who can grant access" is how mature organizations avoid Owner sprawl. If your only tool is Owner, you cannot make that split.
Scope: where the role applies
A role is only half of a role assignment; the other half is scope — the level at which it applies. You assign a role at a management group, a subscription, a resource group, or a single resource, and it inherits downward: Reader at the subscription means Reader on every resource group and resource inside it. This is why you think about scope as carefully as role. "Contributor on this one resource group" is a tight, sensible grant; "Owner on the subscription" is handing someone the keys to everything beneath it.
The principle underneath: least privilege
All of this serves one idea — give each identity the least access it needs to do its job, at the smallest scope that works. Concretely:
- Someone who only needs to look — auditors, dashboards, on-call read access — gets Reader.
- Someone who builds and operates workloads gets Contributor, scoped to the resource groups they own.
- Owner is reserved for the few who must also manage access — and even then, prefer scoping it as narrowly as the job allows.
Get comfortable saying "Contributor on that resource group, not Owner on the subscription" and you are speaking the language of every security review. The three roles are simple; the discipline is choosing the smallest one that still lets the work happen — and remembering that the gap between Contributor and Owner is a wall you put up on purpose.