Role-Based Access Control – Compliance and Cloud Governance
Role-based access control (RBAC) is used for the access management of cloud resources. This is a critical function for any organization as we do not want unauthorized users to access our resources. You can follow the principle of least privilege and assign RBAC roles to different users to accomplish their daily tasks.
RBAC has built-in roles that provide fine-grained access management of resources. Also, if you want to write a custom role based on your organizational need, RBAC supports custom roles.
The following are some of the use case scenarios of Azure RBAC:
- Allow a user to perform all actions on resources
- Allow a group to manage virtual machines
- Allow a user to work as a help-desk agent and open cases with Microsoft Support
- Allow an application to manage IP addresses
Using RBAC, you can separate out duties within your organization (e.g., Network Admins, Virtual Machine Admins, Billing Admins) and grant them the necessary permissions to perform their respective administrative tasks. Rather than giving unrestricted access to everyone, you could limit the actions that are allowed using RBAC.
Now we will discuss the concepts related to RBAC.
Concepts
Understanding these concepts will help you utilize RBAC more effectively. Also, as an administrator, you should be familiar with these concepts. Without knowing these concepts, it will be hard to assign access in an efficient manner.
RBAC assignment is all about the three Ws (who, what, and where): in simple terms, to whom you want to give the permission (who), the set of permissions you are providing (what), and the scope to which this role is assigned (where). Let’s comprehend these concepts.
Security Principal (Who)
The security principal represents an object in Azure AD (user, group, service principal, or managed identity) that is requesting access to the resources. When you assign a role, you get to choose the security principal to which you want to assign the permissions.
If you assign a role to a group, all members of that group will automatically inherit that role as long as they are part of the group. The security principal represents an identity to which you can assign permissions.
Role Definition (What)
As we discussed in the case of Azure Policy, each role in RBAC has a corresponding definition called the role definition. The role definition will contain a collection of permissions that can be performed by any security principal to which you assign the role.
This definition is defined in a JSON file. The fields that are included in the manifest are name, ID, and description. Apart from these, you will see a set of allowable permissions (Actions), denied permissions (NotActions), and scope for the role.
You can use PowerShell or the Azure CLI to extract the manifest of any role. For example, there is a role called Owner that will give complete read, write, and permissions to delegate access to another user on the assigned scope. In Figure 2.16, you can see that we are using the PowerShell command Get-AzRoleDefinition -Name Owner to see the definition of the role. Also, piping the output to ConvertTo-Json will show you the definition in JSON format.
Similarly, in Azure CLI, you can use az role definition list –name Owner to see the same output. In the CLI, you will directly get the JSON output (refer to Figure 2.17).
When we discuss custom roles, you will learn how you can reuse this definition to create new roles in Azure.