Role-based access control

We learned about the basic concepts of RBAC in Chapter 3, Core Azure Architectural Components, when we looked at assigning access to manage Azure subscriptions for billing and resource management.

To recap  this functionality provided by Azure AD, RBAC is a concept that refers to authorized user access based on defined roles that have been assigned. It allows you to create granular access control to Azure resources through defined roles, as well as through custom roles, and you can segregate duties by granting only the access that’s required to perform the required tasks.

It is a good practice for governance to only allow the minimum access required to complete a task. This is the basis for the principle of least privilege and should always be adopted. So, users are only given access through a role(s) that’s the most appropriate for the tasks they need to carry out.

This enhances governance and control of user access management as the permissions are not given directly to individuals or groups but given to roles; each role has a set of associated permissions. When a user or group is assigned that role, they receive the role’s associated permissions.

It is a good practice not to assign individual users to RBAC but to add users to groups and then assign RBAC to the groups; it is easier for governance and control group membership this way.

Roles are specified at what level they apply and are inherited from the parent level. The following diagram visualizes this approach:

Figure 9.3 – RBAC scope level

RBAC assignment is managed via the Access Control (IAM) blade in the portal for each resource you wish to control access over. RBAC is based on four elements, as follows:

• Security principal: This represents an identity; this can be User, Group, Service Principal, or Managed Identity.
• Role (definition): This represents a collection of permissions the security principal will receive; what actions they can take on the resource, such as delete, write, and so on. There are several built-in roles, and you can create custom roles, as we referenced earlier in this chapter.
• Scope: This represents the resource level that this access will apply to. The scopes from the broadest to narrowest are management group, subscription, resource group, and resource; this is structured in a parent-child relationship. A good practice is not to set the scope too wide and only at the least level needed.
• Role assignments: This represents the process of attaching a role definition to a security principal to provide access; creating a role assignment grants access and removing a role assignment revokes access.

The following are the three core RBAC roles for controlling access to Azure resources:

• Owner: This role has full access to resources. In addition, it can assign access to others.
• Contributor: This role is the same as the Owner role, apart from that it cannot assign access to others.
• Reader: This role can only see resources; it cannot create, edit, delete, or manage any resources.

If you feel that the default permissions of a built-in role may provide too much control or be too restrictive, then a more granular custom role can be created with only the permission associated with your required role; these custom roles can then be assigned to users, groups, and service principals at the management group, subscription, and resource group scope, the same as for the built-in roles.

Custom roles can be shared among subscriptions within the same tenancy’s Azure AD directory; there is a limit of 5,000 custom roles that can be created per directory (Azure China has a limit of 2,000). We will look at creating a custom role in Exercise 2 – creating a custom RBAC role in this chapter.

In this section, we looked at granting least privilege access to resources through the RBAC functionality for all Azure resources. The following section looks at Azure Policy.