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.
New to cloud? CAMPUX is a free, build-first course. Start here →
An Azure Owner has full control of everything in scope, including granting access to other people. A Contributor can create, manage, and delete every resource, but cannot assign roles or manage locks. A Reader can only view. In practice, most humans should get Contributor or less — Owner is for admins and break-glass accounts. Everything below is that idea, drawn out — including the specialized variants (Security Reader, Website Contributor) that the three headline roles get shortened to in real environments.
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 short answer: Contributor can do everything Owner can — create, change, and delete every resource in scope — except one thing: assign roles to other people. That single capability is the only difference. Reader can view everything and change nothing.
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 |
| User Access Administrator | Manage access only — assign roles, but not the resources themselves | Yes — access only |
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.
The Azure Contributor role, precisely
Contributor is the workhorse. It grants full management of every resource in scope: create, read, update, and delete VMs, storage accounts, databases, virtual networks, App Services — the whole catalogue. What it deliberately withholds is the Microsoft.Authorization/*/write and /*/delete family of actions, which is the technical way of saying it cannot create or edit role assignments and cannot create or remove management locks. (The exact excluded-action list has grown over time — as of 2026 it also blocks things like blueprint assignments and gallery sharing; check the Contributor definition on learn.microsoft.com for the current list rather than trusting any blog, including this one.) In plain terms: a Contributor can build and run anything, and can grant nothing.
Three things Contributor cannot do that surprise people:
- Assign roles. Not even to grant a teammate Reader on a resource group the Contributor fully controls.
- Create or delete management locks. A lock placed by an admin stays there — a Contributor cannot remove a delete lock to get a resource out of the way. That interplay is its own topic: Azure resource locks.
- Read data inside data-plane services by default. Contributor can delete a storage account but is not automatically allowed to read the blobs in it — more on that below.
Whether you assign it at the subscription or a resource group, it is the same role definition — only the blast radius changes (covered under scope, below). That resource-group-scoped Contributor is the grant most working engineers should hold on the environments they operate.
The Azure Reader role, precisely
Reader is view-only. It grants the */read actions across resources in scope — configuration, properties, metadata, metrics — and no write or delete of any kind. A Reader cannot start or stop a VM, cannot change a setting, and cannot assign roles. It is the correct grant for auditors, finance reviewing cost, and on-call staff who need to see state without the ability to change it.
Two caveats. First, Reader on the control plane does not automatically grant data-plane access: seeing that a storage account exists is not the same as reading the blobs inside it, which is a separate data role. Second, "read" still exposes configuration — resource settings, network topology, tags — so Reader at a broad scope is not a nothing-grant; it is a reconnaissance-grade view of your estate. Scope it like you mean it.
Owner, and why almost nobody should have it
Owner is Contributor plus access management: everything Contributor can do, plus the ability to assign and remove roles for anyone else in scope. That one addition changes the character of the role entirely. An Owner can quietly widen their own access, grant access to others, and remove the locks and assignments that were put there to constrain them. Owner is not "Contributor but more convenient" — it is the role that controls who holds every other role.
In a healthy tenant, Owner shows up in exactly three places: a small set of subscription or management-group admins, break-glass emergency accounts, and (temporarily) whoever created the subscription. Day-to-day engineering work never needs it. If you find yourself reaching for Owner "to be safe," reach for Contributor plus a conversation instead — and if people genuinely need standing admin rights, put them behind just-in-time elevation with Privileged Identity Management rather than a permanent assignment.
User Access Administrator, the mirror image
User Access Administrator is the inverse of Contributor. It grants only access management — the ability to assign and remove roles — and no ability to manage the resources themselves. Pair it with Reader (or Contributor) and you can hand someone the power to grant access without also handing them Owner. This is how larger organisations split "who can change things" from "who can grant access," and it is why Owner should be rare. Microsoft has since added a more constrained Role Based Access Control Administrator role that can assign roles but only from an allowed list — worth reaching for when even User Access Administrator is broader than the job needs.
The scoped and specialized variants
The long tail of Azure's built-in roles is mostly the three headline roles cut down to one service or one plane. A few come up constantly:
Security Reader
The Azure RBAC Security Reader role is Reader for your security posture: it can view Microsoft Defender for Cloud recommendations, alerts, security policies, and security states, but cannot change any of them or dismiss anything. It is the right grant for a SOC analyst or auditor who reviews findings without remediating. One disambiguation that trips people: Microsoft Entra ID has a directory role also called Security Reader, which grants read access to identity-security features (Identity Protection, sign-in reports, and similar). Same name, different system — the Azure RBAC one governs resources, the Entra one governs the directory, and holding one gives you nothing in the other.
Website Contributor
The Website Contributor role is Contributor shrunk to App Service: it lets you manage web apps — deploy, configure, restart — but not the App Service plans they run on, and, like every Contributor variant, it cannot assign roles. Its siblings follow the same pattern: Virtual Machine Contributor for compute, Network Contributor for vNets and NSGs, SQL DB Contributor for databases. Each is "full control of one resource type, no access management."
Subscription Contributor vs resource-group Contributor
People search for a "subscription Contributor role" as if it were a different role. It is not — there is one Contributor role definition, and what changes is the scope you assign it at. Contributor on a subscription means full management of every resource group and resource inside it; Contributor on one resource group means full management of that group and nothing beyond. Same permissions, wildly different blast radius. The scope model is the other half of every role decision, and it gets a section of its own below.
Azure RBAC roles list: the common built-in roles
Azure ships hundreds of built-in roles, but a small set covers the vast majority of real assignments. These are the ones worth knowing by name — the four general-purpose roles at the top, then a handful of the service-specific roles you meet constantly in practice.
| Built-in role | What it grants | Typical use |
|---|---|---|
| Owner | Full management of all resources plus the right to assign roles | Subscription/tenant admins — kept to a small few |
| Contributor | Full management of all resources, but cannot assign roles | Engineers who build and operate workloads |
| Reader | View all resources; change nothing | Auditors, cost reviewers, on-call read access |
| User Access Administrator | Manage access only — assign and remove roles, nothing else | Splitting access-granting from resource work |
| Role Based Access Control Administrator | Assign roles, but only from a constrained allowed list | Delegated access management with guardrails |
| Virtual Machine Contributor | Create and manage VMs; cannot grant access, and cannot manage the vNet or storage they attach to | Teams that own compute but not networking |
| Network Contributor | Manage network resources — vNets, NSGs, load balancers; cannot grant access | Network teams owning connectivity |
| Website Contributor | Manage App Service web apps, but not the App Service plans beneath them; cannot grant access | App teams deploying and operating sites |
| Security Reader | View Defender for Cloud recommendations, alerts, policies, and security states; change nothing | SOC analysts and security auditors |
| Storage Blob Data Contributor | Read, write, and delete blob data (data plane), not the storage account itself | Apps and identities that read/write blobs |
| Key Vault Administrator | Full data-plane access to keys, secrets, and certificates in an RBAC-enabled vault | Managing secrets in Key Vault (RBAC model) |
| Key Vault Secrets User | Read secret values only from an RBAC-enabled vault | Apps that need to fetch a secret at runtime |
Two patterns to notice. First, the service-specific roles (Virtual Machine Contributor, Network Contributor) are scoped Contributors — full control of one resource type, no access management. Second, the Data roles (Storage Blob Data Contributor, Key Vault Secrets User) grant data-plane access, which is separate from the control-plane management that Contributor or Owner give. A Contributor on a storage account can delete the account but is not automatically allowed to read the blobs inside it; that takes a data role. Getting that split right is one of the most common RBAC gotchas.
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. We drill the full scope hierarchy — management group down to resource — hands-on in Class 8, RBAC & Azure Policy.
Which role do I actually give people?
All of this serves one idea — give each identity the least access it needs to do its job, at the smallest scope that works. The practical decision list:
- Someone who only needs to look — auditors, dashboards, on-call read access — gets Reader; a security reviewer gets Security Reader.
- Someone who builds and operates workloads gets Contributor at resource-group scope. This is the default answer, and it covers far more requests than people expect.
- A team that owns one service type gets the matching service Contributor — Website Contributor, Virtual Machine Contributor, Network Contributor — instead of the general one.
- Someone who manages access but not resources gets User Access Administrator or Role Based Access Control Administrator, not Owner.
- Owner is reserved for the few who must do both — admins and break-glass accounts — ideally time-boxed through PIM rather than standing.
- When every built-in role is either too wide or too narrow, build a custom role: clone the nearest built-in definition and trim its actions. It is more upkeep than a built-in, so treat it as the fallback, not the default.
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.
Questions people also ask
What is the difference between Owner and Contributor in Azure?
Both can create, change, and delete every resource in scope. The only difference is access management: Owner can assign roles to other people, Contributor cannot. If a person only needs to build and operate workloads, Contributor covers it — Owner adds nothing except the power to grant access.
What can the Azure Contributor role do?
Contributor can create, configure, and delete every type of resource in its scope — VMs, storage, networks, databases, App Services. It cannot assign roles, cannot create or remove management locks, and does not automatically get data-plane access such as reading blob contents or Key Vault secret values.
What is the Azure Reader role?
Reader is the view-only built-in role. Assigned at a subscription, it can see every resource group and resource beneath it — configuration, metadata, monitoring data — but cannot create, change, or delete anything, and cannot assign roles. It is the right fit for auditors and on-call visibility.
What is the Security Reader role in Azure?
The Azure RBAC Security Reader role grants read-only access to security information: Microsoft Defender for Cloud recommendations, alerts, security policies, and security states. It cannot change or dismiss anything. Microsoft Entra ID has a separate directory role with the same name that covers identity-security data instead — they are different roles in different systems.
Can a Contributor assign roles in Azure?
No. Contributor grants full access to manage resources but explicitly excludes role assignment. To hand out access to others, an identity needs Owner, User Access Administrator, or the newer Role Based Access Control Administrator role instead.
Does Owner include Contributor permissions?
Yes. Owner is Contributor plus one thing: the ability to assign roles in Azure RBAC. There is no resource-management action Contributor can take that Owner cannot; the roles differ only in whether access management is included.
Do Azure RBAC roles inherit down through scope?
Yes. Assign a role at a management group, subscription, or resource group and it applies to everything beneath that scope. Reader at the subscription means Reader on every resource group and resource inside it, which is why picking the smallest correct scope matters as much as picking the smallest correct role.
Does the Contributor role let you read blob or Key Vault data?
Not by itself. Contributor is a control-plane role — it can create, configure, and delete a storage account or Key Vault, but reading the blobs or secret values inside them is data-plane access, granted by separate roles such as Storage Blob Data Contributor or Key Vault Secrets User. Control-plane management and data-plane access are distinct in Azure RBAC.