[BASIC] Role-Based Access Control – RBAC

The topic that we cover today seems pretty basic … but to be honest, Azure Role-Based Access Control (RBAC) is one of the mayor issues I see in most environments.

So, let’s have a look how we can control access in Microsoft Azure…

What are Roles in Azure?!

When you are spinning up your first Azure Subscription you use an account to do this. Depending on your contract and Azure AD situation, it will be a Microsoft LiveID / Microsoft Account, e.g. when using MSDN / Visual Studio Subscriptions. Or it is an Azure AD Account from your company, as you may have received Account Owner Rights in an Enterprise Agreement.

No matter how, as soon as you have created the first subscription, your Account will become Administrator and Owner of this Subscription. And here we go. You have used your first role in Azure: „Owner“. What happened is, that a Security Principal (User, Group, App) got access to Azure Ressources.

The role (defined by a role definition) defines the allowed and denied actions someone can do. To have specific use-cases covered there are pre-defined roles. And there are many more roles than the „Owner“ Role, for example the three main roles:

• Owner – has ownership with full access
• Contributor – can contribute to anything, this means create, delete, change – but cannot change permissions
• Reader – can read all resources, but not create, delete or change anything

Other roles are defined to allow specific actions, like VM Contribution or Network Administration.

A list of all built-in roles is available in the Microsoft Docs. Every role has pre-defined permissions on specific Resource Types. You can check the documentation to find out, or use the preview feature in the Azure Portal to show, for which resources a specific role will get Read, Write, Delete and Other Actions rights.

So let’s keep in mind that roles are used to assign specified permissions to a security principal.

What are Scopes in Role-Based Access Control?!

But now one question comes up: Where do I get access? Is this role for full Azure?

This is where Scopes come to action. Everytime you assign a role you are not just choosing whom and which role you are assigning. You also have to define the scope of this assignment.

This can be on one of four levels:

• Management Group
• Subscription
• Resource Group
• Resource

How to Define Role-Based Access Control?!

With this combination of roles, scopes and security principals you can define very granular access rights. As you could allow only access to networking components in a specific Resource Group for a network administrator role. They will never see other resources, and also cannot mess up things they are not responsible for.

In the end you have to define your way to administrate Azure. But let me tell you: „Everyone is Owner“ is not a good choice.

You can define the RBAC assignments via the Azure Portal. But you can allso use PowerShell, CLI, REST API or you can integrate into a template. So could aim for „Role-Based Access Control as Code“ (RBACaC) 🙂

It is also possible to create a Blueprint … but this is the topic of a later post.

RBAC Limits

There are some known Limits to RBAC. Normally not a problem, but especially when you work in larger environments, it can be a problem:

• Role assignments per Azure subscription 2,000
• Role assignments per management group 500
• Custom roles per tenant 5,000
• Custom roles per tenant (specialied clouds: GOV, DE, CN) 2,000

NO-GO – Live IDs / Microsoft Accounts

One last thing I would like to mention: never use Live IDs / Microsoft Accounts in your Azure RBAC when you are in an Enterprise environment. As those accounts are private, you have no control. If someone leaves the company (or a partner) then you will never figure this out. The Administrator will take the Live ID on to next job … or even worse will use it to play XBox with it … you do not want to have this in your Azure Environment.