RBAC in Azure: A Practical Guide

What is Azure RBAC?

Azure role-based access control (Azure RBAC) enables access management for Azure resources. It’s an authorization system built into the Azure Resource Manager. You can use Azure RBAC to define which specific users should be allowed access to Azure cloud resources and assign a set of privileges for each user group. Let’s learn more about the specifics.

Azure RBAC vs Azure ABAC

As mentioned earlier, Azure RBAC allows you to manage access to Azure resources, defining what users can do with resources and their access areas. It lets you use role definitions and role assignments to control access. However, it does not offer fine-grained access management and can be difficult when managing hundreds of role assignments.

Azure attribute-based access control (ABAC) works differently.

Azure ABAC allows you to add role assignment conditions to achieve fine-grained access control. It builds on Azure RBAC, letting you add attributes for specific actions. Each role assignment condition provides an additional, optional check to a role assignment. Once you set it up, the condition can filter down permissions provisioned as a part of the role definition and assignment. 

Azure RBAC Concepts

Azure RBAC Roles

In Azure RBAC, a role definition is a set of permissions (role). It defines users’ actions, such as write, delete, and read. You can define high-level roles, such as an owner, or specific roles, such as a virtual machine (VM) reader.

Azure provides various built-in roles, including a virtual machine contributor role that allows users to create and manage VMs. If the built-in roles do not satisfy your requirements, you can also define Azure custom roles. You can use data actions to grant access to data stored in a specific object. 

Scope

The term scope refers to a set of resources with specific access. It enables you to grant the relevant security principal to a certain role. Limiting the scope means limiting the scope of resources at risk if the security principal is compromised.

Azure RBAC lets you specify a scope at four levels, including a management group level, a subscription level, a resource group level, and a resource level. Azure structures scopes in a parent-child relationship, with each hierarchy level making the scope more specific. It lets you assign roles at any of the four levels. However, note that the level you choose determines how the role is applied. 

Azure also lets you use management groups, a level of scope above subscriptions. However, management groups support complex hierarchies. The diagram below illustrates an example of a hierarchy of management groups and subscriptions.

Role Assignments

Role assignments enable you to attach role definitions to specific users, groups, service principals, or managed identities at a certain scope. When creating a role assignment, you grant specific access, and removing the assignment revokes this access.

Here is a diagram that illustrates an example of a role assignment: 

This example assigns a contributor role to the marketing group—only for the pharma-sales resource group. It enables all users in the marketing group to create or manage Azure resources in the pharma-sales resource group. However, it does not provide marketing users with access to resources external to the pharma-sales resource group.

Azure Groups

Role assignments are transitive for groups, allowing users to gain permissions assigned to groups. If user A is a member of group B and group B is a member of group C with its own role assignment, user A gets the permissions in group C’s role assignment.

Azure RBAC uses an additive model to prevent issues when users get several overlapping role assignments. You can see an example of this principle in the image below. A certain user is granted a reader role by a resource group and a contributor role at the subscription level. The sum of the reader and contributor permissions is the contributor role. The reader role assignment has no impact.

Best Practices for Azure RBAC

Only Grant the Access Users Need

With Azure RBAC, you can create isolation between different teams, granting each team only the access they need to get the job done. 

Instead of granting unlimited permissions to everyone with an Azure subscription or resource, you can only allow specific actions within specific scopes. Avoid assigning broad roles, even if they seem more convenient at first. When you create a custom role, include only the permissions your users need. This ensures that there’s less risk if a principal account is compromised.

The following diagram shows the recommended pattern for granting permissions in Azure RBAC.

Use Azure AD Privileged Identity Management

To protect privileged accounts from malicious cyberattacks, Azure Active Directory Privileged Identity Management (PIM) can be used to reduce privilege issuance time and improve visibility through reports and alerts. PIM helps protect privileged accounts by providing temporary privileged access to Azure AD and Azure resources. Access is time-limited, after which privileges are automatically revoked.

Assign Roles Using Unique Role ID Instead of the Role Name

Role names may change over time, but the role ID always stays the same. Some common examples of changes to role names is when you are using your own custom role and decide to change the name, or when you are using a preview role that has (Preview) in the name. When the role is released from preview, it is automatically renamed.

To ensure consistency over time, it is a good idea to always assign users to a role ID when assigning roles using scripting or automation. This way, scripts won’t break if the name changes in the future. 

Assign Roles to Groups and Limit Subscription Owners

To make it easier to manage role assignments, do not assign roles directly to users. Instead, assign roles to groups. Assigning roles to groups instead of users minimizes the number of role assignments. Note that Azure imposes restrictions on the total role assignments allowed per subscription.

Microsoft recommends having a maximum of 3 owners for each Azure subscription, to reduce the likelihood of a breach by a compromised or malicious insider.

Cloud RBAC with Frontegg

Frontegg provides out of the box RBAC model implementation. Customers can now create their own roles and permissions which represent their product models and use cases. Additionally, Frontegg empowers the end users to create custom roles to represent their permissions model, without having to change a single line of code in the product. Sounds too good to be true? Try it out now.