Access policies vs RBAC in Azure - Visual Side-by-Side Comparison

Process Flow - Access policies vs RBAC

User requests access

↓

Check RBAC roles assigned

Yes↓

Allow or deny based on role permissions

↓

If no RBAC role, check Access Policies

Yes↓

Allow or deny based on access policy permissions

↓

Access granted or denied

When a user requests access, Azure first checks RBAC roles assigned. If no suitable role is found, it checks access policies. Access is granted or denied based on these permissions.

Execution Sample

Azure

User requests to read a secret from a Key Vault
Check RBAC role: Key Vault Secrets User?
If yes, allow read
Else check access policy for read permission
Allow or deny accordingly

This example shows how Azure evaluates RBAC roles first, then access policies, to decide if a user can read a secret from a Key Vault.

Process Table

Step	Check	Condition	Result	Next Action
1	User requests read access	N/A	Request received	Check RBAC roles
2	Check RBAC role 'Key Vault Secrets User'	Role assigned?	No	Check access policies
3	Check access policy for read permission	Permission granted?	Yes	Allow access
4	Access granted to user	N/A	Access allowed	End

💡 Access granted after checking access policy since RBAC role was not assigned

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
RBAC Role Assigned	False	False	False	False
Access Policy Permission	Unknown	Unknown	True	True
Access Granted	False	False	True	True

Key Moments - 3 Insights

Why does Azure check RBAC roles before access policies?

Azure prioritizes RBAC roles because they provide broad, role-based permissions. If a suitable RBAC role exists, access is granted or denied immediately without checking access policies, as shown in execution_table step 2.

Can a user have access if they have no RBAC role but an access policy allows it?

Yes, as shown in execution_table step 3, if no RBAC role is assigned, Azure checks access policies. If the access policy grants permission, access is allowed.

What happens if neither RBAC roles nor access policies grant permission?

Access is denied because neither method grants permission. This is implied after step 3 if the access policy permission is false.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Azure decide to check access policies?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Refer to the 'Next Action' column in step 2 where it moves to check access policies if RBAC role is not assigned.

According to variable_tracker, what is the value of 'Access Granted' after step 3?

A False

B Unknown

C True

D Depends on RBAC

💡 Hint

Check the 'Access Granted' row under 'After Step 3' column in variable_tracker.

If the user had the RBAC role assigned, how would the execution table change?

A Step 3 would still check access policies

B Step 2 result would be 'Yes' and access granted immediately

C Step 4 would deny access

D Step 1 would be skipped

💡 Hint

Look at step 2 condition and result; if role assigned is 'Yes', access is allowed without checking policies.

Concept Snapshot

Access policies and RBAC both control Azure resource access.
Azure checks RBAC roles first for broad permissions.
If no RBAC role applies, it checks access policies.
Access is granted if either grants permission.
RBAC is role-based; access policies are resource-specific.
Use RBAC for general roles, access policies for fine control.

Full Transcript

When a user requests access to an Azure resource, the system first checks if the user has an RBAC role assigned that grants the needed permission. If such a role exists, access is granted or denied based on that role. If no suitable RBAC role is found, Azure then checks access policies specific to the resource. If the access policy grants permission, access is allowed. Otherwise, access is denied. This flow ensures broad role-based permissions are evaluated first, followed by more specific access policies. For example, a user without the 'Key Vault Secrets User' RBAC role may still read a secret from a Key Vault if an access policy grants read permission. Variables like 'RBAC Role Assigned' and 'Access Policy Permission' track these checks step-by-step. Understanding this sequence helps clarify how Azure manages access securely and flexibly.