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.