Use Azure RBAC for Access

Your subscription is brimming with resources, but you're not sure who should be able to see them, let alone modify them. The default approach — giving everyone 'Contributor' access — is a security nightmare waiting to happen. This lesson shows you how to use Azure RBAC for access control to grant the right permissions to the right people, using the least privilege possible, and how to do it without breaking anything.

The problem this lesson solves

If you've ever shared an Azure subscription with a team, you've likely hit the permission panic: someone needs read access to a storage account, but the only way you know is to add them as an Owner or Contributor. That works, but it gives them far more power than they need — they could delete resources, change security settings, or accidentally run up your bill. The core problem is that you are not using Azure RBAC for access control; you're relying on broad, blunt administrative roles.

This lesson gives you a clear, repeatable method to assign fine-grained permissions using Azure's built-in role definitions. You'll learn how to scope those roles to a specific resource, resource group, or subscription, and how to verify that the permissions you intend are actually in effect.

Core concept / mental model

Think of Azure RBAC as the door locks and security badges of your cloud estate. Someone enters your building (the Azure subscription) and presents their badge (the security principal — a user, group, or service principal). The badge is checked against the doors they're allowed through (the scope), and the level of access they get is defined by their role (the job description: guest, employee, floor manager, etc.).

The magic of RBAC is that permissions are inherited down the hierarchy. If you assign a role at the subscription level, it flows down to every resource group and resource in that subscription. Assign at the resource-group level, and it only affects that group and its contents. Assign at the resource level, and it applies to that single resource.

Pro tip: Always think in terms of who, what, and where. Who is the security principal? What role (permission set) are they getting? Where is the scope (subscription, resource group, or resource)?

How it works step by step

Using Azure RBAC for access control is a three-step process: define the security principal, choose the correct role, and set the scope.

1. Identify the security principal. This is the identity that needs access — a user, a group, or a service principal (the identity for an application or automation).
2. Choose the right role. Azure offers dozens of built-in roles that cover common scenarios: Owner, Contributor, Reader, and specific ones like Storage Blob Data Reader or Virtual Machine Contributor.
3. Set the scope. Decide whether the role applies to the whole subscription, a resource group, or a specific resource. The narrower the scope, the safer.

Once assigned, Azure checks that role at every request. The permission is effective almost immediately, though sometimes there's a slight propagation delay (a minute or two).

Hands-on walkthrough

Let's put this into practice. You'll create a resource group, a storage account, and then assign a reader role to a user or a service principal. We'll use the Azure CLI for speed and reproducibility.

Step 1: Create a resource group and a storage account

# Create a resource group (if you don't have one)
az group create --name rbac-demo-rg --location eastus

# Create a storage account
az storage account create --name rbacdemosa123 --resource-group rbac-demo-rg --location eastus --sku Standard_LRS

Step 2: Find the object ID of the user or group you want to give access

# Get the object ID of a user (replace email)
az ad user show --id user@example.com --query id -o tsv

# Or get the object ID of a group
az ad group show --group "My DevOps Team" --query id -o tsv

Step 3: Assign the Reader role at the resource-group scope

# Assign the Reader role to the user at the resource-group level
az role assignment create \
  --assignee <object-id> \
  --role "Reader" \
  --scope /subscriptions/<subscription-id>/resourceGroups/rbac-demo-rg

Step 4: Verify the assignment

az role assignment list --assignee <object-id> --scope /subscriptions/<subscription-id>/resourceGroups/rbac-demo-rg

You should see the new assignment in the output. To test it, log in as that user and try to list the storage account keys — it should fail, because Reader doesn't include key management permissions.

Step 5 (optional): Remove the assignment

az role assignment delete \
  --assignee <object-id> \
  --role "Reader" \
  --scope /subscriptions/<subscription-id>/resourceGroups/rbac-demo-rg

This cleans up after your test.

Compare options / when to choose what

Azure provides several ways to control access, and RBAC is only one of them. Here's how RBAC stacks up against the alternatives:

When to choose what:

• Use RBAC roles for human users and for service principals when you need fine-grained, auditable permissions.
• Use managed identities when an Azure resource (like a function or a VM) needs access to another resource — it removes the need to handle secrets.
• Avoid access keys except for quick prototyping; they give full access to the resource and are hard to rotate.

Troubleshooting & edge cases

"Permission denied even though I assigned the role"

This is the most common issue. Check these possible causes:

• Propagation delay. In rare cases, it can take a few minutes for the assignment to fully propagate. Wait and retry.
• Scope mismatch. You assigned at the resource level, but you're testing at the subscription level. Double-check the --scope parameter.
• Inherited permission overwritten. If a deny assignment exists (uncommon), it can block permission even if you're allowed. Check for deny assignments with az role assignment list --include-groups --include-inherited and look for --deny.
• Wrong principal. You assigned to a group, but the user isn't in that group, or you mis-typed the object ID.

"The user can still do too much"

You may have assigned Owner or Contributor when they only need read access. Review your role assignments regularly using:

az role assignment list --scope /subscriptions/<subscription-id> --include-groups --include-inherited

This shows every assignment in the subscription, including inherited ones.

"I can't assign a role because I lack 'Microsoft.Authorization/roleAssignments/write'"

Only Owner or User Access Administrator roles at that scope can create assignments. If you can't assign, ask your admin to grant you User Access Administrator at the needed scope.

What you learned & what's next

You now know how to use Azure RBAC for access control: how to define a security principal, choose an appropriate role, set the correct scope, and verify the assignment. You can apply the least-privilege principle, meaning your users and services only get the minimum permissions they need. You also know how to troubleshoot the most common issues, such as propagation delays and scope mistakes.

In the next lesson, you'll build on this foundation by exploring managed identities — a powerful way to give Azure resources permissions without managing credentials. That's a natural next step because it reuses the same RBAC concepts but adds the convenience of automatic identity management.

Now go ahead and try assigning a Reader role to a colleague in a test resource group. You'll see how quickly Azure RBAC gives you controlled, auditable access.