Azure RBAC Roles Overview

One of the most fundamental and important functions of any cloud system is Access management and security. When you allow someone access to Azure, the best practice it to use the principle of least privilege (POLP). Users logging into Azure should only have the permissions to complete their duties and nothing else. Role-based access control (RBAC) is the system that allows granular access to Azure resources.

What is RBAC?

RBAC is an ARM based security and authorization system built on Azure. Building RBAC on ARM allows all Azure resources to be controlled via the RBAC roles. RBAC uses .JSON files to specify who has access to what and where that access in valid.

Using RBAC, it is possible to grant one user access to Virtual Machines only and another user access to Web Apps only. This is especially useful when you have multiple types of engineers accessing a system, such as Network engineers and  App Developers.


How does RBAC work?

Resource permissions are controlled via Role Assignments, which are essentially containers containing permissions elements. Role assignments are given names which represent the access they provide, such as “Virtual Machine Administrator”

Role assignments consist of three permission elements which are Security principal, Role definition and scope. This three elements together are what allow a RBAC role to grant or deny specific access to a user. The Security principal sets “Who” has access, the definition sets “What” they have access to and finally the scope dictates “Where” this access applies. The elements are covered in more detail below.


Security principal

The security principal is an object that represents who will have the access, usually either a User or a group in Active Directory. When you use or create an RBAC role, you must choose who the role will be assigned to and this is what is known as the “security principal“.


Role definition

The role definition is the element that dictates what a user will have access to. This is the element that sets all the permissions on a role.

Every definition has a set of “Actions”. When you add an operation to the Actions element, it means the role will have access to that specified operation. You can also set “NotActions” which is a list of operations the role does not have access to.

Below is an image of the Role definition. As you can see an “Action” is set, which will allow all access to Storage within Azure.




The final element be aware of in a RBAC role is the scope. The Scope is the boundary that the access applies to. Scopes can be assigned to subscriptions or they can be used to allow access at granular levels by assigning scopes to either management groups, resource groups or even single resources.

As an example, Senior Network engineers may be granted access to all network resources within a subscription. Whereas a junior network engineer may only be granted access to network resources within a specific resource group.

Cloudy Tip: RBAC Scopes are structured in a parent-child relationship, be aware of this when creating custom RBAC roles.


Built in Roles

Azure comes with over 70 built-in roles, these roles are based around the most common tasks or job types. This make using RBAC roles easy from the start. A full list of the default roles can be found here.

Within the 70 roles are four basic fundamental roles, they are Owner, Contributor, Reader and User Access administrator. The rest of the built-in roles allow management of specific Azure resources such as “Billing Reader” which grants access to read billing data only.

Cloudy Tip: RBAC Roles can only be used on the Portal or via ARM APIs, it cannot be used on the Azure classic deployment model.


Custom Roles

If one of the built in RBAC roles are not fit exactly what you need, you create a custom RBAC role. This allows you to specify your own actions, scopes and operations meaning you can create a role with access to any Azure resource within any scope.

Custom roles are stored in Azure AD and can be shared across subscriptions. You can create custom roles using Azure PowerShell, CLI or the RESP API but not the Azure portal. You also have a limit of up to 2000 custom roles.

Cloudy Tip: When reading a RBAC role in its JSON format, you will know its custom if the “IsCustom” attribute is set to true. (Shown below)



Example Role

Below is a screenshot of a custom role. It’s called “VM Start/Restart Role”, the purpose of this role is to only allow access to start or restart a VM. The scope of this role is the whole subscription. My next Post will be a tutorial on how to create this role yourself for practice.




RBAC is a very powerful and useful tool for Access management on Azure. The built-in roles make using the system very simple and easy to setup. Custom roles allow a very useful granular method to allowing access and permissions to Azure resources. I suggest anyone not too familiar with RBAC to read my next post which will be a tutorial on creating Custom RBAC roles.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top