Access policies vs RBAC in Azure - CLI Comparison

Introduction

Access policies and RBAC are two ways to control who can do what in Azure. They help keep resources safe by giving the right permissions to the right people or apps.

When you want to give a user or app permission to read or write secrets in Azure Key Vault.

When you need to control access to Azure resources like virtual machines or storage accounts with detailed roles.

When you want to limit access to specific actions without giving full control over a resource.

When you want to manage permissions centrally across many resources using roles.

When you want to allow an app to access a resource without sharing user credentials.

Commands

This command sets an access policy on the Azure Key Vault named 'myKeyVault' to allow the user or app with the given object ID to get and list secrets.

Terminal

az keyvault set-policy --name myKeyVault --object-id 12345678-1234-1234-1234-123456789abc --secret-permissions get list

Expected Output

No output (command runs silently)

→

--name - Specifies the name of the Key Vault.

→

--object-id - Specifies the Azure AD object ID of the user or app.

→

--secret-permissions - Defines the allowed secret operations.

This command assigns the built-in 'Reader' role to the user or app with the given object ID for the specified resource group scope. It uses RBAC to control access.

Terminal

az role assignment create --assignee 12345678-1234-1234-1234-123456789abc --role "Reader" --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup

Expected Output

{

  "canDelegate": null,

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Authorization/roleAssignments/abcdef12-3456-7890-abcd-ef1234567890",

  "name": "abcdef12-3456-7890-abcd-ef1234567890",

  "principalId": "12345678-1234-1234-1234-123456789abc",

  "principalType": "User",

  "roleDefinitionId": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",

  "scope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup",

  "type": "Microsoft.Authorization/roleAssignments"

}

→

--assignee - Specifies the user or app object ID to assign the role.

→

--role - Specifies the role name or ID to assign.

→

--scope - Defines the resource or resource group where the role applies.

This command shows the details of the Key Vault, including its access policies, so you can verify the permissions set.

Terminal

az keyvault show --name myKeyVault

Expected Output

{

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.KeyVault/vaults/myKeyVault",

  "location": "eastus",

  "name": "myKeyVault",

  "properties": {

    "accessPolicies": [

      {

        "objectId": "12345678-1234-1234-1234-123456789abc",

        "permissions": {

          "secrets": [

            "get",

            "list"

          ]

        },

        "tenantId": "87654321-4321-4321-4321-cba987654321"

      }

    ]

  },

  "resourceGroup": "myResourceGroup",

  "type": "Microsoft.KeyVault/vaults"

}

→

--name - Specifies the Key Vault name to show.

This command lists the RBAC role assignments for the user or app at the resource group scope to verify their permissions.

Terminal

az role assignment list --assignee 12345678-1234-1234-1234-123456789abc --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup

Expected Output

[

  {

    "principalId": "12345678-1234-1234-1234-123456789abc",

    "roleDefinitionName": "Reader",

    "scope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup"

  }

]

→

--assignee - Filters role assignments by user or app object ID.

→

--scope - Filters role assignments by resource scope.

Key Concept

If you remember nothing else from this pattern, remember: Access policies control permissions inside specific services like Key Vault, while RBAC controls permissions across Azure resources using roles.

Common Mistakes

Trying to use RBAC roles to control Key Vault secret permissions directly.

Key Vault requires access policies for secret permissions; RBAC roles alone do not grant secret access.

Use 'az keyvault set-policy' to assign secret permissions, and RBAC for broader resource access.

Assigning RBAC roles without specifying the correct scope.

The role assignment will not apply where expected, causing permission errors.

Always specify the correct scope, such as a subscription, resource group, or resource.

Not verifying permissions after setting policies or roles.

You might think permissions are set but they are not, leading to access failures.

Use 'az keyvault show' and 'az role assignment list' to confirm permissions.

Summary

Use 'az keyvault set-policy' to assign access policies for Key Vault secrets.

Use 'az role assignment create' to assign RBAC roles for broader Azure resource access.

Verify permissions with 'az keyvault show' and 'az role assignment list' commands.