Azure Permissions 101: How to manage Azure access effectively

While onboarding customers to Azure they ask what permissions do we need to assign to our IT Ops or to partners and I’ve seen customer gets confused when we ask them for Azure AD permission for some task and they say we’ve provided owner access on Azure Subscription why Azure AD permission is required and how this is related. So thought of writing this blog to share how many permission domains are there when you use Azure.

We will talk about these RBAC Domain:

 

• Classic Roles

• Azure RBAC Roles

• Azure AD Roles

• EA RBAC

• MCA RBAC

• Reserved Instance RBAC

 

Classic Roles

 

So let us talk about RBAC first – When I used to work in Azure Classic portal it used to be fewer roles. Mostly Account Admin, Co-Admin and Service Admin. The person who created subscription would become service Admin and if that person wanted to share the admin privilege, then he used to assign co-administrator role to the other guy

So when you go to Subscription -> IAM blade you’ll still see this. I have seen customers trying to provide owner access just try to use this Add Co-administrator button. Now you know the difference. This is not mean for providing someone access to ARM resource.

 

 

Azure RBAC

 

Let us talk about ARM RBAC now. When we moved to Azure RBAC from classic. We started with more fine-grained access control. With each service there was a role e.g. virtual machine contributor for managing VMs, Network contributor for managing network and so on. So, the user gets stored in Azure AD itself, but the permissions are maintained at subscription, resource group, management group level or resource level.

In each RBAC we have Actions which basically tells the role what it can perform.

 

The actions are part of the control plane. Which you get access to manage the service and its settings or configurations. We also have data plane actions. Which provides you the actual data access. Let us take an example of Azure Blob storage, if you get reader role you would be able to see the resource itself but will not be able to see the actual data in blob storage if you authenticate via Azure AD. If you want to see the actual data, then you can get storage blob data contributor role assigned to the ID and you can see the actual data. Similarly, there are services which expose data actions e.g. Azure Key vault, Service Bus.

Getting into where this RBAC roles can be assigned at Resource, Resource Group level or management group level is another discussion which I will cover in another blog post.

 

Azure AD Roles

 

This is used when you deal with Azure AD itself or services of which roles are stored in Azure AD like SharePoint, Exchange, or Dynamics 365. Dealing with Azure AD roles might be required during multiple instances, for example using service which creates service principals in the backend like app registration. Azure Migrate, Site recovery etc. would require Azure AD permissions to be assigned to your ID.

This RBAC Domain is separate from the Azure RBAC, this gets stored in Azure AD itself and managed centrally from roles and administrator’s blade.

The person who created the tenant gets a global admin role and then we have fine grained access based on the roles.

 

Though Azure AD roles are different than Azure RBAC which we assign to subscriptions, a global admin can elevate himself and get access to all the subscriptions in his tenant through a toggle.

 

Once you enable this toggle you get the user access administrator role at the root scope under which all the management group gets created. So eventually you can access all the subscriptions.

 

This is a rare and exceptional procedure that requires consultation with your internal team and a clear justification for its activation.

 

EA RBAC

 

If you are an enterprise customer and have signed up for the EA Agreement from Microsoft, as a customer in order to create subscriptions and manage billing you need to log on to EA portal which is now moved to Azure portal. Hence we’ve set of 6 RBAC permissions which can be used from cost management + billing section in Azure portal.

• Enterprise administrator

• EA purchaser

• Department administrator

• Account owner

• Service administrator

• Notification contact

 

Which set of permission is assigned at specific hierarchy can be explained through the below image. this is copied from Microsoft learn documentation mentioned below.

 

 

Below is the sample screenshot which you see when you click on cost management + billing portal. Here you will see Accounts, Departments, subscriptions.

 

 

MCA RBAC

 

If you have purchased MCA, then you get hierarchy for permissions to be assigned. Top level permissions are assigned at the billing scope and then billing profile level.

 

Billing account owner and Billing profile owner are the most common role you will use. More roles are mentioned in the article below which you can go through.

 

Reserved Instance RBAC

 

A common request from customers I get, I have got contributor/owner access to the subscription still I do not see the reserved Instance which is purchased by my colleague. Few years back the person who purchased reservation used to be the one who provided access to others by going to individual reservation. This is still possible but now you can get access to all reservations in the tenant.

Reservations when purchased by an admin he can see/manage it and seen by EA Admin or a person with reservation administrator role.

 

 

 

You can do this via PowerShell too, check this document for more information.

 

More information regarding who got access to RI is mentioned in the article below.

https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/view-reservations

Happy Learning!

You can find more such article at https://www.azuredoctor.com/ 
Public blogpost: https://www.azuredoctor.com/posts/rbac-101/