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…
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:
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.
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:
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.
There are some known Limits to RBAC. Normally not a problem, but especially when you work in larger environments, it can be a problem:
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.
Dieser Post ist auch verfügbar auf:
German
2 Comments
[…] queries are done with the RBAC rights of the user executing them. So take care that you at least have a read right to query for the […]
[…] we figured out last week, Azure Role-Based Access Control (RBAC) is a very important thing, when it comes to the Management of Microsoft Azure. But there is another […]