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.

Practice

1. What is the main difference between Azure Access Policies and RBAC?

easy

A. RBAC controls network traffic; Access Policies manage user passwords.

B. Access Policies grant permissions directly on resources; RBAC assigns roles at scopes.

C. Access Policies are used only for virtual machines; RBAC is for databases.

D. RBAC is a legacy system; Access Policies are the modern replacement.

Solution

1. Step 1: Understand Access Policies

   Access Policies give permissions directly on specific resources, like a key vault.

2. Step 2: Understand RBAC

   RBAC assigns roles with permissions at different levels like subscription or resource group.

3. Final Answer:

   Access Policies grant permissions directly on resources; RBAC assigns roles at scopes. -> Option B

4. Quick Check:

   Access Policies = direct resource permissions, RBAC = role-based scopes [OK]

Hint: Access Policies = direct, RBAC = role at scope [OK]

Common Mistakes:

• Confusing Access Policies with RBAC roles
• Thinking RBAC only applies to virtual machines
• Assuming Access Policies control network settings

2. Which of the following is the correct way to assign an RBAC role using Azure CLI?

easy

A. az network policy add --role <role> --user <user>

B. az accesspolicy set --user <user> --permission <perm>

C. az vm assign-role --user <user> --role <role>

D. az role assignment create --assignee <user> --role <role> --scope <scope>

Solution

1. Step 1: Identify correct RBAC command

   The Azure CLI command to assign RBAC roles is 'az role assignment create' with assignee, role, and scope parameters.

2. Step 2: Verify other options

   Other options mention access policies or unrelated commands which are invalid for RBAC role assignment.

3. Final Answer:

   az role assignment create --assignee <user> --role <role> --scope <scope> -> Option D

4. Quick Check:

   RBAC role assignment uses 'az role assignment create' [OK]

Hint: RBAC role assignment uses 'az role assignment create' [OK]

Common Mistakes:

• Using access policy commands for RBAC
• Mixing VM or network commands with RBAC
• Omitting the scope parameter

3. Given this Azure CLI command output snippet for a key vault access policy:

"permissions": {"keys": ["get", "list"], "secrets": ["get"]}

What permissions does this policy grant?

medium

A. Allows only listing keys, no secret access.

B. Allows creating and deleting keys and secrets.

C. Allows getting and listing keys, and getting secrets.

D. Allows full control over keys and secrets.

Solution

1. Step 1: Read the permissions for keys

   The keys permission includes 'get' and 'list', so it allows reading and listing keys.

2. Step 2: Read the permissions for secrets

   The secrets permission includes only 'get', so it allows reading secrets but no other actions.

3. Final Answer:

   Allows getting and listing keys, and getting secrets. -> Option C

4. Quick Check:

   Permissions match get/list keys and get secrets [OK]

Hint: Check each permission list carefully for allowed actions [OK]

Common Mistakes:

• Assuming 'get' means create or delete
• Confusing 'list' with full control
• Ignoring secret permissions

4. You assigned an RBAC role to a user but they still cannot access a key vault secret. What is the most likely cause?

medium

A. The user lacks an access policy granting secret permissions on the key vault.

B. The RBAC role was assigned at subscription level, which is too broad.

C. The user needs to restart their Azure portal session.

D. RBAC roles do not control access to key vault secrets.

Solution

1. Step 1: Understand RBAC vs Access Policies for Key Vault

   Key vault secrets require access policies to grant permissions, RBAC alone may not suffice.

2. Step 2: Analyze the problem

   Even if RBAC role is assigned, without an access policy granting secret permissions, access is denied.

3. Final Answer:

   The user lacks an access policy granting secret permissions on the key vault. -> Option A

4. Quick Check:

   Key vault secret access requires access policies [OK]

Hint: Key vault secrets need access policies, not just RBAC [OK]

Common Mistakes:

• Assuming RBAC alone controls key vault secrets
• Thinking subscription-level RBAC restricts access
• Believing portal restart fixes permission issues

5. You want to secure an Azure Key Vault so that only a specific user can read secrets, and a group can manage keys. Which approach follows best practices?

hard

A. Assign specific RBAC roles to the user for secret read (Key Vault Secrets User) and to the group for key management (Key Vault Crypto Officer).

B. Create an access policy granting the user secret read permission; assign an RBAC role to the group for key management.

C. Use access policies for both user and group to grant all permissions.

D. Assign the user an RBAC role for secrets and the group an access policy for keys.

Solution

1. Step 1: Choose RBAC as best practice

   Azure recommends RBAC for Key Vault. Disable access policies and enable RBAC authorization on the Key Vault.

2. Step 2: Assign granular roles at Key Vault scope

   Assign 'Key Vault Secrets User' role to user (get/list secrets). Assign 'Key Vault Crypto Officer' role to group (manage keys).

3. Final Answer:

   Assign specific RBAC roles to the user for secret read (Key Vault Secrets User) and to the group for key management (Key Vault Crypto Officer). -> Option A

4. Quick Check:

   RBAC Secrets User + Crypto Officer roles [OK]

Hint: RBAC best practice: Secrets User + Crypto Officer roles [OK]

Common Mistakes:

• Trying to mix Access Policies and RBAC (not possible)
• Using access policies for everything (legacy method)
• Assigning overly broad roles or permissions