In terms of cloud computing, access control plays a vital role in order to manage permissions effectively. Any organization using the cloud need to provide wide range of permissions to their employees as well as third part as part of the operational activities. IT resources, for instance, might require higher level of permission on those cloud services as compare to business users because IT employees are responsible to managing, designing/developing solutions, providing supports, managing access control, networking, securities, and all stuffs. However, end users are those who are only using applications of those cloud services therefore, they require less or lower level of permissions. Additionally, rights to know the current access of user(s) is another crucial concern for the cloud for betterment of access control.
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).
There is plethora of other use cases in which we can use Azure RBAC.
Key concept
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. (Which permission)
Scope
Scope is considered as the set of resources on which access will be applied. We can, for example, assign permission to the specific resource(s) like azure app service, Azure SQL, Azure VM likewise, to single/multiple resource group, subscriptions or management group as portrayed.
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.
Furthermore, in this article, we will check Azure role-based access from Portal which is one easiest way to handle it.
We will find one common tab in every resources of Azure that is Access Control (IAM) as shown,
This option is available for all the scopes like Azure services/resources, resource groups, subscriptions, and management groups.
Conclusion
In this article, we have learned about Azure role-based access control which gives an efficient way of managing access control to Azure resources based on scope, security principal and roles. In Azure, we have complete role assignment options considering all kinsd of standard scenarios. In the next article, I will demonstrate on Azure RBAC from the Azure portal.