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.
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 (Windows Virtual Desktop) in a specific subscription. Or allow users to create Azure App service as well as Logic (multiple) services with contribute, read, or owner roles.
Giving different accesses to different scopes like management groups, subscriptions, resource groups or Power Platform resource outsourcing.
Granting access to an application to access to resources as well.
We can do many to many relations between roles, scopes, and users or groups (security principal).
Azure RBAC Type
In-built RBAC Roles – In-built roles are predefined by Microsoft i.e. Owner, Contributor, and Reader.
Custom Roles – Custom Roles are created by an 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.
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.