Following on from our previous blog on Azure Policy, we are continuing with the security theme and covering Role-Based Access Control (RBAC), which is part of Azure’s Identity and Access Management Framework.
RBAC is great because you can assign permissions by role instead of to individuals, one by one, saving a lot of time. You’re going to either use lots of the built-in roles, or create custom roles that represent the common tasks of jobs within your company: customer service department, sales department, technical department. You can create rules and give very granular access to those people. Instead of creating 20 different roles for each person, you can assign a role by department and people can have multiple roles.
RBAC is actually a concept rather than a specific service or resource you can deploy in Azure. You’ll find the Access Control (IAM) blade on most Azure resources:
(Click image to enlarge)
If you’ve worked with any form of user and group management in the past, Azure IAM works on a similar principle. You assign users to groups, and groups (or individual users) to roles. There are a lot of built-in roles. The screenshot below shows just the top few:
(Click image to enlarge)
Behind each of these role definitions are a set of restrictions to a specific Azure API endpoint. For day-to-day BAU (business as usual) through the Azure portal, you don’t tend to care that much about the API endpoints, but you do need to understand them if you want to create custom roles.
My advice is stick with out-of-the-box; it usually meets 90% of the requirements. Only deep dive on custom roles if you need something special, such as a role that will be used by several in-house applications that need to access a small subset of functionality in Azure.
With a new Azure subscription, I tend to start with two groups, one for Subscription Owners (at the subscription level) and one for Resource Group Contributors (at the resource group level). Subscription Owners have owner role, applied on the subscription itself. Resource Group Contributors have contributor role, and this is applied individually on the resource groups as you create them. I have a very small number of people (one or two) in the Subscription Owners’ Group, and everyone else who is responsible for resource deployment in the Resource Contributors’ Group.
This has pros and cons (like everything else). Changes at the subscription level tend to be as a direct response to business requirements, whereas in the resource groups themselves you tend to get BAU or project operational changes. This is good from a governance perspective but has the following side effects:
-
Nobody in the Resource Contributors’ Group can actually create the resource group; that has to be done by someone in the Subscription Owners’ Group.
-
The subscription owner will also need to apply the Resource Contributors’ Group to the resource group (you could use an Azure Policy to do this automatically).
-
Sometimes a resource deployment (actioned by someone in the Resource Contributors’ Group) will require a resource provider to be registered at the subscription level. The installation will usually show a big red error message. Someone in the Subscription Owners’ Group will need to register it manually. Usually the owner will have to do this via Az Cli.
If you want to know more about the impact of RBAC during SAP migrations to Azure or you need any help or advice on Microsoft Azure, please feel free to contact us.
Useful links:
Leave a Comment: