Azure RBAC and Azure access control
Misconfiguring Azure access control is a common issue that I've encountered more often than not as a consultant working with Azure now over a decade. I've even published a course about the subject and other Azure security best practices if you are interested in going deeper than this post.
For some, the Azure role-based access control (Azure RBAC) with Built-in roles and different scopes might feel like a burden and you would rather just leave the defaults on without getting deeper into the subject. Unfortunately, that can lead to unwanted risks for you, which you probably want to avoid.
In this post, I go through the most common misconfigurations and some best practices on how you should configure your Azure access control. For a deeper look, check out my book Azure Security Handbook.
Why do so many fail Azure access control configuration and why does it matter?
Owner is the default role for a new subscription. An owner can manage user access, as well as manage any resources in the scope that it is assigned. This means that if a user is assigned an Owner role of the Subscription, they can create, read, update and delete any Azure resource or RBAC assignment in that Subscription.
Basically, the Owner can create an unlimited amount of new cost-incurring Azure services, turn off production, delete databases and remove access from others.
Azure RBAC default role assignment should be changed
For many companies, Azure authorization is broken. Most commonly this is by adhering to the defaults of a new Subscription: every user having the Role-Based Access Control (RBAC) role of Owner in the Subscription scope.
How to secure Azure access control with the right RBAC roles?
The owner role should be considered a privileged role, and its usage should be minimized. You should separate the duties of User access management and editing resources. Those who need access to manage resources should be granted the Contributor RBAC role.
For those who need access to manage access control, instead of Owner, you should use the User Access Administrator role.
Azure built-in roles
There are four Azure built-in roles, Contributor, Owner, User Access Administrator, and Reader. To follow the principle of least privilege, you should move to make your default RBAC access control assignments Contributor instead of the Owner, whenever you can.
The following picture explains more the relationships between the core built-in Azure RBAC.
Contributor Azure RBAC allows the user to perform most administrative actions, such as creating and deleting containers, virtual machines or databases. Crucially, the Contributor role does not allow the user to perform access control changes, such as inviting new users to your Azure subscription, or removing existing access. For access control management, you should assign the User Access Administrator role instead of the Owner role. This let’s the holder of this built-in role perform these changes, but does not allow modifying the cloud resources in any way.
By separating the Owner role holders into Contributor and User Access Administrators, you already follow the security best practice of segregation of duties.
What access to give the DevOps team members?
So what built-in Azure roles should you give to your individual DevOps team members? Those who need to make changes to your cloud resources, developers, database administrators, site reliability engineers and so on, should be assigned the Contributor role. This gives them freedom to create new cloud services in a self-service manner.
Project managers, scrum masters should be assigned the User Access Administrator built-in role, so that they can add and remove team members to the Azure subscription.
Team members who are designing requirements and not making changes to the cloud services directly, such as security engineers or other subject matter experts, should be assigned the Reader built-in RBAC role so they can read Azure audit logs.
How to use Azure RBAC scopes
In order to avoid unnecessary risks, it is good to understand how Azure RBAC scopes work.
Role-Based Access Control assignments are inherited, so in the case of a Subscription-scope role assignment, you will have access to any of the resources created by others in the same resource group, even if the resources and resource groups are created later.
This means that even if you intend to give a developer access to modify their own Azure App Service, assigning them an Azure built-in role in the Subscription scope gives them access to any Azure SQL Databases in the same Azure Subscription. And what’s more, if the database administrator creates a new Azure SQL Database in the subscription, the developer will automatically get access to the new database, too!
As a rule of thumb, you should minimize Subscription scope assignments and prefer Resource Group scope assignments. This will let you manage Azure RBAC access in a more granular way. Further down the line of your Azure journey, you can use this same approach to assign roles in a Resource level, or in some cases, even sub-resource level! For example, you could assign a group of support engineers a Contributor role in the specific Azure App Service resource, instead of assigning them in a wider scope.
Using scopes in a smart way also lets you avoid using custom Azure RBAC roles. To understand why it’s a smart idea to avoid using custom Azure RBAC roles, you can watch my video about the matter that is part of Azure security best practices course.
