Role-Based Access Control (RBAC) in Azure - Step-by-Step Execution

Process Flow - Role-Based Access Control (RBAC)

User requests access

↓

Check user's assigned roles

↓

Match role permissions with requested action

Yes No↓

Allow access

↓

Log access decision

RBAC checks what roles a user has, then allows or denies actions based on those roles' permissions.

Execution Sample

Azure

az role assignment create --assignee [e-mail] --role Reader --scope /subscriptions/12345

Assigns the Reader role to a user for a specific subscription scope.

Process Table

Step	Action	Input	Check	Result
1	User requests to read resource	User: [e-mail], Action: read	Check roles assigned to user	Roles found: Reader
2	Check if Reader role allows read	Role: Reader, Action: read	Reader role includes read permission	Permission granted
3	Allow access	User: [e-mail], Action: read	Access allowed	User can read resource
4	Log access decision	User: [e-mail], Action: read	Log success	Access logged
5	User requests to write resource	User: [e-mail], Action: write	Check roles assigned to user	Roles found: Reader
6	Check if Reader role allows write	Role: Reader, Action: write	Reader role does not include write permission	Permission denied
7	Deny access	User: [e-mail], Action: write	Access denied	User cannot write resource
8	Log access decision	User: [e-mail], Action: write	Log failure	Access denied logged

💡 Access decisions made based on role permissions; no further checks needed.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 5	After Step 6	Final
User Roles	None	Reader	Reader	Reader	Reader	Reader
Requested Action	None	read	read	write	write	write
Permission Check Result	None	Pending	Granted	Pending	Denied	Denied
Access Decision	None	Pending	Allowed	Pending	Denied	Denied

Key Moments - 2 Insights

Why does the user get denied when trying to write even though they have the Reader role?

Because the Reader role only allows read permissions, not write. This is shown in execution_table rows 5 and 6 where the write action is checked against Reader role permissions and denied.

What happens if a user has multiple roles with conflicting permissions?

Azure RBAC grants the most permissive access from all assigned roles. So if any role allows the action, access is granted. This is implied in the role check step where all roles are evaluated.

Visual Quiz - 3 Questions

Look at the execution_table, what is the permission check result at step 2?

A Pending

B Denied

C Granted

D Not checked

💡 Hint

Check the 'Permission Check Result' column for step 2 in execution_table.

At which step does the user get denied access for writing?

A Step 4

B Step 7

C Step 6

D Step 8

💡 Hint

Look for the 'Access Decision' column where access is denied for write action.

If the user was assigned the Contributor role instead of Reader, how would step 6 change?

A Permission check would grant write

B Permission check would be pending

C Permission check would still deny write

D No permission check needed

💡 Hint

Contributor role includes write permissions, so permission check would grant write.

Concept Snapshot

Role-Based Access Control (RBAC) in Azure:
- Assign roles to users/groups at scopes (subscription, resource group, resource).
- Roles define allowed actions (read, write, delete).
- When user requests action, Azure checks assigned roles for permission.
- Access granted if any role allows the action.
- Use Azure CLI or portal to assign roles.

Full Transcript

Role-Based Access Control (RBAC) in Azure works by assigning roles to users or groups. Each role has permissions that allow certain actions like reading or writing resources. When a user tries to do something, Azure checks their roles to see if the action is allowed. If yes, access is granted; if not, access is denied. For example, a user with the Reader role can read resources but cannot write. This process ensures secure and organized access management in cloud environments.