Azure role-based access control: Overview
In this tutorial, we will get to know about Azure role-based access control (RBAC) and its use.
Access management for cloud resources is a critical function for any organization that is using the cloud. It helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Moreover, Azure RBAC is an authorization system built on Azure Resource Manager for providing fine access management of Azure resources.
What can I do with Azure RBAC?
- Firstly, you can allow one user to manage virtual machines in a subscription and another user to manage virtual networks
- Secondly, you can allow a DBA group for managing SQL databases in a subscription
- Thirdly, you can allow a user for managing all resources in a resource group, such as virtual machines, websites, and subnets
- Lastly, allow an application to access all resources in a resource group
Azure RBAC working
The way you control access to resources using Azure RBAC is to assign Azure roles. This is a key concept for understanding the enforcement of permissions. However, a role assignment consists of three elements:
1. Security principal
A security principal is an object that represents a user, group, service principal that is requesting access to Azure resources. Moreover, you can assign a role to any of these security principals.
2. Role definition
A role definition is a collection of permissions. A role definition lists the operations to perform, read, write, and delete. Roles can be high-level, like an owner, or specific, like virtual machine reader.
Further, Azure includes several built-in roles that you can use. For example, the Virtual Machine Contributor role allows a user to create and manage virtual machines. If the built-in roles don’t meet the specific needs of your organization, you can create your own Azure custom roles.
3. Scope
The scope is the set of resources that the access applies to. When you assign a role, you can further limit the actions allowed by defining a scope. This is helpful if you want to make someone a Website Contributor, but only for one resource group. However, in Azure, you can specify a scope at four levels:
- management group
- subscription
- resource group
- resource
How Azure RBAC determines if a user has access to a resource
The following are the high-level steps that Azure RBAC uses to determine if you have access to a resource. These steps apply to Azure Resource Manager or data plane services integrated with Azure RBAC. This is helpful to understand if you are trying to troubleshoot an access issue.
- Firstly, a user (or service principal) acquires a token for Azure Resource Manager. The token includes the user’s group memberships.
- Secondly, the user makes a REST API call to Azure Resource Manager with the token attached.
- Thirdly, Azure Resource Manager retrieves all the role assignments and denies assignments that apply to the resource upon which the action is being taken.
- If a deny assignment applies, it will block access. Otherwise, evaluation continues.
- Then, Azure Resource Manager narrows the role assignments that apply to this user or their group and determines what roles the user has for this resource.
- After that, Azure Resource Manager determines if the action in the API call is included in the roles the user has for this resource. If the roles include Actions that have a wildcard (*), the effective permissions are computed by subtracting the NotActions from the allowed Actions. Similarly, the same subtraction is done for any data actions.
- Actions – NotActions = Effective management permissions
- DataActions – NotDataActions = Effective data permissions
- If the user doesn’t have a role with the action at the request scope, then, access is not allowed. Otherwise, any conditions are evaluated.
- If the role assignment includes conditions, they are evaluated. Otherwise, access is allowed.
- If conditions are met, access is allowed. Otherwise, there is no access.
Reference: Microsoft Documentation