RBAC in Azure: Roles, Scopes and Security Principals Explained

Introduction

I decided to start a short series about Role‑Based Access Control (RBAC) in Azure for a few reasons:

• In many of my upcoming posts, I will refer back to RBAC, so I want readers to have a solid foundation and be familiar with the concept in depth.
• Security is one of the most critical aspects of IT systems, and a good understanding of RBAC is in my view, a key factor in building more secure solutions.
• I have often seen teams still relying on connection strings in Azure, even when there is no strong reason to do so. RBAC provides a more secure and manageable alternative.

Let’s go through this series together, and by the end you’ll be equipped with the skills to make your Azure solutions more secure and easier to manage.

What is RBAC and why it matters

Role‑Based Access Control (RBAC) is a general access management model used across many IT systems. Azure provides its own implementation of RBAC, tailored to cloud resources and services.

Don’t think of RBAC as something unique to Azure; it’s a general security model that Azure also implements.

The idea is simple: permissions are tied to roles, and roles are assigned to principals such as users, groups, or applications at a given scope. This way, you manage who can do what and where/at which scope, without relying on broad credentials like connection strings or shared keys. By structuring access through roles and scopes, Azure RBAC enforces least privilege, reduces risks, and makes systems easier to manage at scale.

Security principal (who)

A security principal is the identity to which permissions are assigned. It can be a user, a group of users, a service principal (representing an application). In RBAC, the security principal answers the question: who is allowed to perform actions?

RBAC role (what)

An RBAC role defines a set of permissions that determine what actions a security principal can perform. Roles can be built‑in (like Reader, Contributor, or Owner) or custom, defined through JSON. Each role bundles allowed actions (the green keys) and excludes (the red key), ensuring that principals only get the access they need.

Scope (where/at which scope)

A scope specifies where the role assignment applies. In Azure, scopes can be at different levels. Assigning a role at a broader scope (like a subscription) cascades permissions down to all contained resources, while narrower scopes provide more fine‑grained control.

Security boundary

In Azure, the security boundary is defined by the Microsoft Entra tenant. Every identity, whether a user, group, service principal exists within a tenant, and all RBAC assignments are scoped inside that boundary.

That’s enough theory for now so let’s move on to some specific examples!

Demo

Now that we’ve gone through the fundamentals of RBAC – who (security principals), what (RBAC roles), and where (scopes) it’s time to see how these concepts play out in practice. In the following use cases, we’ll walk through concrete examples of role assignments in Azure. Each scenario highlights a different angle of RBAC, showing how permissions are applied and how scopes influence access.

ℹ️RBAC roles can be assigned in various ways, but if this topic is new to you, I encourage you to open the Azure Portal, select the resource at the scope where you want to assign the permission, then choose Access Control (IAM) → Add → Add role assignment. From there, select an RBAC role, choose a security principal, and continue with the flow.

Use case 1

Objective: The function app fa‑001 needs to:

• Read blob data from the sa‑001 storage account.

• Who: The function app fa‑001 (using a service principal).
• What: Assign the Storage Blob Data Reader role to grant read‑only access to blob containers and contents.
• Where: Scope the role assignment to the sa‑001 storage account.

This way, fa‑001 can read blob data only from sa‑001, following the principle of least privilege which is just simply essential for protecting your systems.

The principle of least privilege – grant only the minimum access needed to perform required tasks, reducing risk and exposure.

Use case 2

Objective: The function app fa‑001 needs to:

• Publish messages to all Storage Account queues within the rg‑001 resource group (sa-001 , sa-002 , sa-003).

• Who: The function app fa‑001 (using a service principal).
• What: Assign the Storage Queue Data Message Sender role, which allows sending messages to storage account queues.
• Where: Scope the role assignment to the rg‑001 resource group.

By assigning the role at the resource group level, the permission automatically propagates down to all resources within that group. This means fa‑001 can send messages to the queues in sa‑001, sa‑002, and sa‑003 without needing separate role assignments.

ℹ️ If a new storage account is added to rg‑001, fa‑001 will automatically gain the same permission there as well. This flexibility makes management easier but can also lead to unintended behaviors if permissions are broader than intended.

Use Case 3

Objective: Three users User 1 ,User 2 , User 3 need to:

• read secrets from a kv-001 Azure Key Vault, with more users likely to be added soon.

• Who: Members of the Entra group ‘admins’ which represents an independent security principal.
• What: Assigned the Key Vault Secrets User role, which allows reading secrets stored in a Key Vault (but not directly through the Azure Portal).
• Where: Scope the role assignment to the specific Key Vault kv‑001.

By assigning the role to the group rather than individual users, all current members of admins gain the ability to read secrets in kv‑001. If new users are added to the group later, they automatically inherit the same access without requiring additional role assignments. This makes management flexible and scalable, though it also means permissions can expand quickly if group membership isn’t carefully controlled (the Access Reviews feature helps address this challenge by ensuring group memberships remain appropriate over time).

Summary

This series introduces Role‑Based Access Control (RBAC) in Azure, highlighting how it improves security and simplifies management. RBAC ties permissions to roles, which are assigned to principals (users, groups, or applications) at a chosen scope. This enforces least privilege, reduces reliance on insecure methods like connection strings, and scales effectively across resources.

Key concepts include:

• Who: Security principals (users, groups, service principals).
• What: RBAC roles define allowed actions.
• Where: Scopes determine where permissions apply, with broader scopes cascading down.
• Boundary: All assignments exist within a Microsoft Entra tenant.

From here, the series moves into practical examples of role assignments. In the next post, we’ll explore Control Plane vs Data Plane Permissions.

Thanks for reading, and see you in the next post!