How to Define Azure Role-based Access Control (RBAC)

In this guide, you will learn about defining roles and assigning them using the Azure CLI, allowing you to use code to script RBAC role assignments.

Oct 12, 2020 • 7 Minute Read

Subscribe to the newsletter

Introduction

Azure allows cloud administrators to manage access to their resources using role-based access control (RBAC). This allows specific permissions to be granted to users, groups, and apps. When implemented correctly, this enhances security by applying the principle of least privilege. However, when your cloud infrastructure is large with dozens of apps and hundreds of users, managing all these permissions becomes difficult to maintain in a reproducible and transparent way.

In this guide, you will learn about defining roles and assigning them using the Azure CLI. This allows you to use code to script RBAC role assignments to simplify deployment and maintenance. A basic understanding of bash is assumed knowledge for this guide.

Role Definition and Assignments

In the Azure CLI, there are two components to manage:

Role definitions define a set of permissions. These permissions include which data and actions an assignee is granted or denied access to.
A role assignment is a mapping between a role definition, a scope, and an assignee. An assignee could be a user in your active directory domain, a service principal that represents your app, or a security group that contains one or many users. A scope is a property that allows administrators to limit a role definition to a subscription, resource group, or specific Azure resource.

To clarify, your Azure subscription has a set of built-in role definitions already. For example, you can create a role assignment where you assign the role reader to the security group developers at the scope of your my-web-app resource group. This allows all the members of the developers security group to view resources contained in the my-web-app resource group but not make any changes.

Create Role Assignments in the Azure CLI

To assign roles, you need three components:

The role definition
The assignee
The scope of the assignment. If you don't provide a scope, it will default to the entire subscription.

To assign the reader scope to the developers security group, run the following commands:

          # get a list of all roles definitions
az role definition list --query "sort_by([],&roleName)[].{name:name,roleType:roleType,roleName:roleName}" -o tsv

# save security group object's id to a variable
developers_security_group=$(az ad group list --query "[?displayName=='developers'].{objectId:objectId}" -o tsv)

# assign the role by omitting the scope. This defaults to entire subscription.
az role assignment create --role "Reader" --assignee $developers_security_group

# assign the role and specify a resource group scope.
az role assignment create --role "Reader" --assignee $developers_security_group --scope /subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/resourceGroups/my-web-app
    

Create Role Definitions in Azure CLI

You can also create your own role definitions. This is useful when you have a standard set of permissions you want to give to apps at different scopes. For instance, say you have 100 resource groups, and each resource group has two apps inside it. Each app is allowed permission to read data from a storage account and Cosmos DB database inside its own resource group only. If you stick to the built-in roles, you will need to separately assign the Cosmos DB Account Reader Role, Storage Blob Data Reader, and Storage Queue Data Message Processor permissions separately to each app.

To define your own role called Custom Data Reader, run the following commands:

          az role definition create --role-definition '{
        "Name": "Custom Data Reader",
        "Description": "Read data from storage accounts and cosmos DB Databases.",
        "Actions": [
          "Microsoft.DocumentDB/*/read",
          "Microsoft.Storage/storageAccounts/blobServices/containers/read",
          "Microsoft.Storage/storageAccounts/queueServices/queues/delete",
          "Microsoft.Storage/storageAccounts/queueServices/queues/read",
          "Microsoft.Storage/storageAccounts/queueServices/queues/write"
        ],
        "DataActions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
          "Microsoft.Storage/storageAccounts/queueServices/queues/messages/delete",
          "Microsoft.Storage/storageAccounts/queueServices/queues/messages/read",
          "Microsoft.Storage/storageAccounts/queueServices/queues/messages/write"
        ],
        "NotDataActions": [
        ],
        "AssignableScopes": ["/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"]
    }'


# assign the new custom role to an app or group
az role assignment create --role "Custom Data Reader" --assignee $developers_security_group
    

Work with Managed Identities

So far you have assigned roles to security groups. This is useful since it allows you to manage permissions for multiple users at a time.

However, in a micro-services environment, you may have hundreds of apps, but individual apps need only a subset of the roles a user may have. In this case, you want to separately identify the app and assign only the roles that it needs.

Microsoft has a set of services that support managed identities. These identities make it easy to manage permissions since you don't need to manage secrets like passwords or client credentials yourself. Like users, they can also have roles assigned to them.

To assign a role, first query the identity and then create a role assignment at the appropriate scope.

          # query the principalId of a webapp
APP_IDENTITY=$(az webapp identity show -n my-web-app -g my-web-app --query "{principalId:principalId}" -o tsv)

# assign a role to that webapp
az role assignment create --role "Custom Data Reader" --assignee $developers_security_group --scope /subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/resourceGroups/my-web-app
    

Conclusion

RBAC provides a rich set of capabilities that allow you to control access within your organization. By scripting role definitions and assignments, managing a large set of roles is simplified; you can make a widespread change in a predictable way. This also allows you to audit and review changes through source control. To further build on these skills, read more about Azure AD Managed Identities.