In order to follow this chapter hands-on, you will need access to an Azure Active Directory tenant as a global administrator. If you do not have access to one, you can enroll with a free account: https://azure.microsoft.com/en-in/free/.
You will also need an Azure subscription of which you have owner permissions with a resource group deployed and a virtual machine of any size that is part of the resource group.
Creating a custom RBAC role
RBAC is a general term used for restricting access to users, based on a role. It works on the Just Enough Access (JEA) concept where a specific user/group will be provided minimum access to perform their specific job on a specific resource. Custom roles can only be created and updated by a user who has the following role assigned: Microsoft.Authorization/roleDefinitions/write permissions.
When it comes to RBAC, it is very important to understand how and where it is applied. Azure RBAC can be applied to the following security principals:
- User
- Group
- Service principal
- Managed identity
Now that we know what security principals support RBAC, the next step is to have a look at role definitions. A role definition is a collection of permissions that can be applied to security principals; however, in Azure, this is referred to as a role. A role is what determines what operations are allowed – for example, read access, write access, or the deletion of resources.
The following are some built-in roles within Azure:
- Owner role: This is the role that includes all permissions; you can read, add, and remove resources. You also have the capability to add and remove other users to and from resources as owners or other roles.
- Contributor role: This role has the same permission as an owner, except you cannot add or remove additional users to and from resources.
- Reader role: This role has the ability to view resources, but cannot amend, add, or remove users or resources.
There are multiple built-in roles within Azure, and it is recommended that you have a look at them: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles.
The next part is to understand scope. Scope is the target resource that you need to assign a role to. In Azure, there are mainly four scope levels that roles can be assigned to:
- Management group
- Subscription
- Resource group
- Resource
The following diagram displays the main scope levels in Azure:
Figure 2.1 – A visual representation of the scope levels in Azure
In summary, RBAC consists of three main sections:
- Security principal: Selects who is going to have access.
- Role: Selects what type of access is going to be assigned to the security principal.
- Scope: Selects the resource that the user and the role will be applied to.
Now that we understand built-in RBAC roles within Azure, let’s take a look at custom RBAC roles.
Note
Azure Active Directory (AD) roles are used to manage the identities within the directory, whereas RBAC in this section is used to define permissions for resources that reside within the relevant subscription or management group.
Custom RBAC roles can be created if the built-in RBAC roles do not meet specific requirements.
Tip
There is a limit of 5,000 custom RBAC roles per Azure directory.
Custom RBAC roles can be created in the following ways:
- The Azure portal
- Azure PowerShell
- The Azure CLI
- The REST API
In this section, we had a look at RBAC in Azure and how it works from a logical perspective.
We encourage you to read further by using the following links, which provide an overview of RBAC and also built-in roles:
- https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
- https://docs.microsoft.com/en-us/azure/role-based-access-control/overview
Now, let’s see how to create a custom role.
