Resource groups in Microsoft Azure is a logical container and help customers to manage multiple resources in constructive manner. When you deploy multiple resources in a logical container then it is necessary to consider the security measures as well. Resource groups provide an option to manage the access control through Access control (IAM).
It offers multiple pre-defined RBAC (role based access control) roles. When you create a new subscription first time in Microsoft Azure, by default azure creates and associates it with an automatically created azure active directory. For example if I create my subscription with email address xyz@hotmail.com then an azure active directory with xyzhotmail will be created in the background. Going forward you can add multiple subscriptions into it.
However, once you are logged in to the Microsoft Azure then you can switch between the directories if you have multiple. But keep a note in your mind that one subscription belongs to only one directory in azure while one directory can belongs to multiple subscription.
RBAC roles can be assigned to the users and groups that are part of the associated azure active directory. Groups can be created in azure active directory while users either can be created in azure active directory or can be associated with their public email addresses.
Here is the list and their one line descriptions provided by Microsoft Azure.
|
Role name |
Description |
|
Can manage API Management service and the APIs |
|
|
Can manage API Management service, but not the APIs themselves |
|
|
Read-only access to API Management service and APIs |
|
|
Can manage Application Insights components |
|
|
Able to start, stop, suspend, and resume jobs |
|
|
Can manage backup in Recovery Services vault |
|
|
Can manage backup except removing backup, in Recovery Services vault |
|
|
Can view all backup management services |
|
|
Can view all billing information |
|
|
Can manage BizTalk services |
|
|
Can manage ClearDB MySQL databases |
|
|
Can manage everything except access. |
|
|
Can create and manage data factories, and child resources within them. |
|
|
Can view everything and connect, start, restart, and shutdown virtual machines |
|
|
Can manage DNS zones and records |
|
|
Can manage Azure Cosmos DB accounts |
|
|
Can manage Intelligent Systems accounts |
|
|
Logic App Contributor |
Can manage all aspects of a Logic App, but not create a new one. |
|
Logic App Operator |
Can start and stop workflows defined within a Logic App. |
|
Can read all monitoring data |
|
|
Can read monitoring data and edit monitoring settings |
|
|
Can manage all network resources |
|
|
Can manage New Relic Application Performance Management accounts and applications |
|
|
Can manage everything, including access |
|
|
Can view everything, but can’t make changes |
|
|
Can manage Redis caches |
|
|
Can manage scheduler job collections |
|
|
Can manage search services |
|
|
Can manage security components, security policies, and virtual machines |
|
|
Can manage Site Recovery in Recovery Services vault |
|
|
Can manage failover and failback operations Site Recovery in Recovery Services vault |
|
|
Can view all Site Recovery management operations |
|
|
Can manage SQL databases, but not their security-related policies |
|
|
Can manage the security-related policies of SQL servers and databases |
|
|
Can manage SQL servers and databases, but not their security-related policies |
|
|
Can manage classic storage accounts |
|
|
Can manage storage accounts |
|
|
Can create and manage support requests |
|
|
Can manage user access to Azure resources |
|
|
Can manage classic virtual machines, but not the virtual network or storage account to which they are connected |
|
|
Can manage virtual machines, but not the virtual network or storage account to which they are connected |
|
|
Can manage classic virtual networks and reserved IPs |
|
|
Can manage web plans |
|
|
Can manage websites, but not the web plans to which they are connected |
Source: Microsoft
Now, you should know how the permission works here. There are three basic RBAC roles that apply to all resource types.
Owner: As suggested by name itself, full access to all the resources and has rights to manage the delegation for others.
Contributor: who can read, write/create and manage but can’t delegate rights to others.
Reader: who can view existing resources but can’t make any changes.
Now, let’s look at the inheritance of the resources. Same as other Microsoft technologies, permission inheritance works in a downwards manner here.
It means Subscription à Resource groups à Resources.
If pre-defined RBAC roles do not fulfill your requirement then you can create your own custom roles through Azure PowerShell, Azure CLI and the Rest API.
InsideMSTech 
I see “(IAM)” showing in reference to RBAC-style access management. However, I see no definition for “(IAM)”. I read in the docs I’ve been able to find that Azure has its own security mechanisms and portals, as one would expect. But coming from an AWS background, IAM sounds a lot like Amazon’s Identity & Access Management.
Can anyone define “IAM” in the Azure context and provide any comparison with Amazon?
LikeLike