Access policies vs RBAC in Azure - Hands-On Comparison

Access Policies vs RBAC in Azure

📖 Scenario: You are managing access to an Azure Key Vault in a small company. You want to control who can read secrets and who can manage the vault itself. Azure offers two ways to control access: Access Policies and Role-Based Access Control (RBAC).In this project, you will create a simple Azure Key Vault access setup using both Access Policies and RBAC to understand their differences and how they work.

🎯 Goal: Build an Azure Key Vault configuration that uses Access Policies to allow a user to read secrets and RBAC to assign a role to another user to manage the vault.

📋 What You'll Learn

Create an Azure Key Vault resource named myKeyVault.

Create an Access Policy that grants read permission on secrets to a user with object ID user-object-id-1.

Create an RBAC role assignment that assigns the Key Vault Contributor role to a user with object ID user-object-id-2.

Use valid Azure Resource Manager (ARM) JSON template syntax.

💡 Why This Matters

🌍 Real World

Managing access to Azure Key Vaults is a common task in cloud security to protect sensitive data like secrets and keys.

💼 Career

Understanding Access Policies and RBAC is essential for cloud administrators and security engineers working with Azure.

1

Create the Azure Key Vault resource

Create an Azure Key Vault resource named myKeyVault in the ARM template with the type Microsoft.KeyVault/vaults and API version 2019-09-01. Set the location to eastus and include an empty properties object.

Azure

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2019-09-01",
  "name": "myKeyVault",
  "location": "eastus",
  "properties": {
    
  }
}
# Add the Azure Key Vault resource definition above

Hint

Define the resource with the exact type, name, location, and apiVersion as specified.

2

Add an Access Policy for secret read permission

Inside the properties of myKeyVault, add an accessPolicies array with one object. This object must have tenantId set to 00000000-0000-0000-0000-000000000000, objectId set to user-object-id-1, and permissions with secrets containing get.

Azure

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2019-09-01",
  "name": "myKeyVault",
  "location": "eastus",
  "properties": {
    // Add accessPolicies array here
  }
}
# Add the accessPolicies array with the specified user and permissions

Hint

Remember to place the accessPolicies inside the properties object.

3

Add an RBAC role assignment for Key Vault Contributor

Add a new resource of type Microsoft.Authorization/roleAssignments with API version 2022-04-01. Set the name to a GUID string 11111111-1111-1111-1111-111111111111. Set properties with roleDefinitionId pointing to the built-in Key Vault Contributor role ID /subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/00482a5a-887f-4fb3-b363-3b7fe8e74483 (use literal string as shown), and principalId set to user-object-id-2. This resource should be separate from the Key Vault resource.

Azure

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2019-09-01",
  "name": "myKeyVault",
  "location": "eastus",
  "properties": {
    "accessPolicies": [
      {
        "tenantId": "00000000-0000-0000-0000-000000000000",
        "objectId": "user-object-id-1",
        "permissions": {
          "secrets": ["get"]
        }
      }
    ]
  }
}
// Add a new resource for role assignment below
# Add the RBAC role assignment resource with the specified properties

Hint

Remember this is a separate resource object in the ARM template array.

4

Complete the ARM template with full resource array

Wrap the two resource objects (the Key Vault and the role assignment) inside a resources array in a full ARM template JSON structure. Include schema as https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json# and contentVersion as 1.0.0.0. The final template should have resources containing both the Key Vault and the role assignment.

Azure

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    // Add the two resource objects here
  ]
}
# Wrap the resources in the ARM template structure

Hint

Make sure the two resource objects are inside the resources array with the correct schema and contentVersion.

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