Understanding Azure RBAC

Role-Based Access Control Simplified

In Azure, user identities are managed in Entra ID, while access to resources is controlled through Azure RBAC.

In this post, we'll break down:

How Azure RBAC works

How to use it to secure your resources

When to create custom roles for fine-grained control

What is Azure RBAC?

Azure RBAC allows you to control who can do what at which scope. Instead of assigning individual permissions one by one to every user (which is messy and error-prone), RBAC lets you define what a "role" can do, and then assign that role to the right identity.

Think of it like this:

Who: The identity to which the role is assigned.

What: The role, which defines the set of permissions granted.

Where (scope): The level at which access applies.

RBAC Components Explained:

1. Security Principal (Who?)

This is the identity that receives the permission. It could be:

A user

A group (e.g., security group)

A service principal (from App Registration)

A managed identity (for apps hosted in Azure)

2. Role Definition (What?)

A role definition is a set of permissions. instead of assigning permission individually, we assign roles instead. Azure operates across two distinct layers of operations:

• Management Plane

This layer covers actions that manage and configure Azure resources, such as creating a virtual machine or assigning roles.

Access is governed by RBAC roles like:

Owner – Full control, including assigning roles

Contributor – Full control, except assigning roles

Reader – View-only access to resources

These are management plane roles, focused on administrative control.

• Data Plane

This governs access to the data within a resource, such as reading blob contents or accessing secrets.

Examples of data plane roles include:

Storage Blob Data Reader – Can read blob data in Azure Storage

Key Vault Reader – Can view secrets, keys, and certificates in Key Vault (read-only)

3. Scope (Where?)

The level at which the access applies:

Management group – top level for multiple subscriptions

Subscription

Resource group

Resource (most granular). example: an azure function app, etc

NB: You can inherit permissions downwards (e.g., from subscription to a resource group).

Demo

Let’s walk through how to assign a data-plane role to a user so they can read and upload blobs in an Azure Storage Account.

In this example, we’ll grant the Storage Blob Data Contributor role at the resource scope (i.e., directly on the storage account). This role provides the necessary permissions to read, write, and delete blobs.

• Navigate to the Storage Account
  Go to the Azure portal and open the storage account where you want to assign permissions.

• Access the IAM Settings
  In the left-hand menu, select Access Control (IAM).

• Go to Role Assignments
  Select the Role assignments tab.

• Add a New Role Assignment
  Click + Add > Add role assignment.

• Choose the Right Role
  Use the search box to find Storage Blob Data Contributor, select it, and click Next.

• Select the Identity Type
  Under Assign access to, choose User, group, or service principal.

• Pick the Member
  Click + Select members, search for the Entra ID user (e.g. user@domain.com), and select them.

• Complete the Assignment
  Click Review + assign, then confirm again to finalize the assignment.

  

This can also be applied to any Azure resource/resource group/subscription/management group and you will be able to select roles related to that scope.

You can find a list of built-in roles here: Azure built-in roles

When should you consider custom roles?

Sometimes, the built-in roles may not be enough as your requirement grow or change, this is where custom role definitions come in.

You should consider creating custom roles when :

You need least privilege access not covered by built-ins

You want to allow specific actions (e.g., read-only + deploy, but no delete)

You need scoped control across multiple subscriptions or resource groups

In a future blog, we will take a look at how to define custom roles and then assign them to identities.

That’s all for today, see you in the next one.