Azure RBAC
Updated: Nov 29, 2022
What is Azure RBAC?
Azure provides flexible role-based access control for Azure resources through which you can efficiently manage users access to azure resources, can allow the level of permission, and can identify their access to various resources. This access control is called as Azure role-based access control i.e., Azure RBAC.
Some scenarios for Azure Access Control (Azure RBAC)
Granting access to different Azure Resources with one or multiple roles. Example: Allow a user to manage Azure App as well as Azure SQL Service. We can give contributor, Reader, owner, Manage role, Monitor reader/contributor, website contributor etc.
Similarly, granting access to subscription level.
Example: allowing a user to create only virtual machine in specific subscription. Or allow user to create Azure App service as well as Logic (multiple) services with contribute, read or owner role.
Giving different accesses to different scopes like management group, subscriptions, resource group or resources.
Granting access to an application to access to resources as well.
We can do many to many relations between roles, scopes and users or group (security principal).
Azure RBAC Type
In-built RBAC Roles - In-built roles are predefined by Microsoft i.e. Owner, Contributor, Reader.
Custom Roles - Custom Roles are created by a admin to maintain the access and compliance policies
What can we do with RBAC?
RBAC allows you to grant access to Azure resources that you control. Suppose you need to manage access to resources in Azure for the development, engineering, and marketing teams. You’ve started to receive access requests, and you need to quickly learn how access management works for Azure resources.
Here are some scenarios you can implement with RBAC.
Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
Allow a database administrator group to manage SQL databases in a subscription
Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
Allow an application to access all resources in a resource group
Azure RBAC Key Concepts
There are three primary components to understand for Azure role-based access control: Security principal (who), Role (what) and Scope(where).
Security Principal is basically representing who is going to get the access like users, group, service principal, and managed identity. (Who are)
Role is a definition of collections of permissions
like read, contribute, owner, delete etc.
Azure RBAC Scope
Scope is the set of resources that the access applies to. When we assign a role, we can further limit the actions allowed by defining a scope. This is helpful if we want to make someone a Website Contributor, but only for one resource group.
In Azure, we can specify a scope at four levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship. You can assign roles at any of these levels of scope.
The relations between security principal, role definition and scope is a kind of many-to-many.
We can assign role(s) to a user or group at a certain scope for access control and again can be revoked by removing a role assignment.
We can assign the same role to multiple users, groups, or managed identity on same or different resources (scope).
We can assign roles using Azure Portal, Azure SDKs, Azure CLI, Azure PowerShell or REST APIs.