A Practical Breakdown for Cloud Administrators and Learners

In a cloud environment, controlling access is just as important as building resources. Azure Role-Based Access Control (RBAC) helps administrators assign permissions carefully and consistently. Whether you’re managing a few VMs or a complex infrastructure, RBAC ensures the right people have the right access to the right resources nothing more, nothing less.

Core Concepts in Azure RBAC

Role: What Can You Do?

A role defines a set of permissions such as “read virtual machines” or “manage storage accounts.” Think of it as a job title with specific duties.

There are two main types:

• Built-in roles: Azure provides roles like Owner, Contributor, Reader, Virtual Machine Contributor, and more than 70 others.
• Custom roles: You can create roles that include only the permissions you need.

Edge Case:
The Reader role allows broad visibility across most services, but it cannot read Key Vault secrets. For that, you need a specific role like Key Vault Reader.

Caution:
The Contributor role allows full read/write access, including deleting resources. Be careful assigning it too broadly.

Assignment: Who Gets the Role?

Roles are assigned to the following types of identities:

• Individual users
• Groups of users (managed through Azure AD)
• Service principals (representing apps or scripts)
• Managed identities (linked to specific Azure resources like VMs)

Tip:
Using groups simplifies administration, especially when onboarding or offboarding users.

Edge Case:
If a user is part of multiple groups with different role assignments, Azure RBAC combines the permissions. The result is the union of all allowed actions — the most permissive set applies.

Scope: Where Can the Role Be Used?

The scope defines where the role is effective in the Azure resource hierarchy:

1. Management group
2. Subscription
3. Resource group
4. Individual resource

Assigning a role at a higher scope level means the permissions apply to everything below that level.
Assigning at a lower level gives more precise control.

Example:
If you assign the Reader role at the subscription level, it applies to all resource groups and resources within that subscription.

Important Note:
Permissions assigned at a lower level do not override more permissive roles granted at a higher level. Azure RBAC evaluates all role assignments and merges permissions.

What the Role Actually Permits

Every role in Azure is made up of one or more actions — defined using operation strings. Examples include:

Microsoft.Compute/virtualMachines/start/action
Microsoft.Storage/storageAccounts/read
Microsoft.Network/networkInterfaces/delete

You can create custom roles using only the actions you need.

Important:
RBAC does not support explicit deny. If you need to restrict actions, you must use Azure Policy or Attribute-Based Access Control (ABAC) instead.

Inheritance: How Permissions Flow

Permissions assigned at higher levels in the hierarchy (e.g., subscription) automatically flow down to lower levels (resource groups and resources).

This is powerful but can lead to unintended consequences if you’re not careful.

Best Practice:
Avoid assigning broad roles (like Owner or Contributor) at the subscription level unless absolutely necessary. Use resource groups or individual resources for more controlled access.

Common Mistakes to Avoid

1. Assigning the Reader role expecting full read access
   The Reader role does not include access to all sensitive data types, like Key Vault secrets.
2. Giving Contributor at the subscription level to everyone
   This results in excessive permissions and poor security hygiene. Assign at the least-privilege level required.
3. Expecting immediate access changes
   RBAC changes can take a minute or two to propagate. Give it time and refresh.
4. Assuming RBAC controls everything
   RBAC controls access to the control plane. It does not manage network access, firewall rules, or NSG settings.
5. Not verifying custom role deployment
   If a custom role isn’t working, make sure it was created and deployed correctly within the intended subscription or tenant.

Finally, I will leave you with this comparison between Azure RBAC and Azure AD roles: