Azure Classic Roles vs. Azure RBAC Roles vs. Azure AD Roles – Compliance and Cloud Governance

Azure Classic Roles vs. Azure RBAC Roles vs. Azure AD Roles – Compliance and Cloud Governance

If you are new to Azure, you will find it a little confusing to understand the distinct roles in Azure and how they are different. When Azure was released, the RBAC roles were not there. We had something called the classic subscription administration roles. There were three roles, and they were used to manage resources and access. The following are the classic roles:

Account Administrator  The user who signs up for the Azure subscription is the Account Administrator. By default, the user will have access to the billing as well as to the service management. There will be only one Account Administrator for a subscription.

Service Administrator  The Account Administrator can delegate the service administration to another user. If the Account Administrator and Service Administrator are two different users, then the Account Administrator will be managing the billing aspects of the subscription, and all resource management will be carried out by the Service Administrator. The Service Administrator role is similar to the Owner role we have in RBAC. There will only be one Service Administrator for a subscription.

Co-administrators  Co-administrators can manage all aspects of resources the same way as Service Administrators; however, Co-administrators cannot delegate access. For example, if you are a Co-administrator, you cannot add another person as a Co-administrator. This action can be done only by a Service Administrator. The Co-administrator role is similar to the Contributor role in RBAC.

These classic roles were assigned at the subscription level, and the idea of scoping was not there in the earlier days. This caused a lot of security concerns as we were not able to give fine-grained access to resources. For example, if you wanted to assign a role to a user for managing virtual machines, there was no customized role at that time. The lowest privilege that you could assign was the Co-administrator role. Since this classic role is defined at the subscription level, the user would end up getting access to all resources. Due to this drawback, Azure produced RBAC when it introduced Azure Resource Manager (ARM). The rest is history; administrators can customize roles, fine-tune the access, and assign them at different scopes.

Now we will shift our focus to Azure AD roles. In Chapter 1 you saw that Azure AD roles are for managing the resources in Azure AD. This is where the difference between Azure AD and Azure RBAC lies. Azure AD roles are created to manage the users, groups, domains, and other objects that are part of Azure AD. Table 2.1 will explain the key differences between these roles.

TABLE 2.1  Comparing Classic, RBAC, and Azure AD Roles

AspectAzure Classic RolesAzure RBAC RolesAzure AD Roles
AccessManages access to Azure resources. Microsoft recommends using Classic roles only for the management of Classic resources.Manages access to Azure resources.Manages access to Azure AD resources like users, groups, domains, and other objects.
ScopeScope is limited to subscription scope.Scope can be defined at multiple levels, starting from management groups, subscriptions, resource groups, and resources.Scope is limited to tenant level.
Role managementCan be managed from the Azure portal and Accounts Portal (reaching EOL).Can be managed from Azure Portal, Azure CLI, Azure PowerShell, ARM templates, SDKs, and REST API.Can be managed from the Azure portal, Microsoft 365 Admin Center, Microsoft Graph API, and Microsoft Azure AD PowerShell module.
Custom rolesNot Supported.Supported.Supported.

Figure 2.19 shows where each of the roles is related and how they fit into the bigger picture.

At this point you are aware that Azure RBAC supports custom roles. In the next section, we will talk about custom roles and how they are created.



Leave a Reply

Your email address will not be published. Required fields are marked *