Managing who can access resources in your Azure environment—and to what extent—is a foundational aspect of security and governance.
In Azure, resource access is controlled via a mechanism called role-based access control, or RBAC, which allows you to assign different permissions to your users and more according to their exact needs.
Here's an overview of how RBAC works in Azure. Jump to:
What is role-based access control used for?
Using predefined permissions to control access to IT resources is nothing new, and you don't need to be an Azure governance master to understand why it's essential to restrict access to certain resources to only those who absolutely need it to get their jobs done—especially in the decentralized context of a cloud environment.
Recommended read: [Book preview] Do you really need a cloud governance plan?, by Jussi Roine
RBAC lets you do just that by providing a flexible way to assign permissions according to the exact level of access required. This time-tested model, which was introduced back in 1992 as a less rigid approach to traditional access management, is built around the concept of roles.
This has several benefits. As explained in this FAQ from the National Institute of Standards and Technology (NIST):
Within an organization, roles are relatively stable, while users and permissions are both numerous and may change rapidly. Controlling all access through roles therefore simplifies the management and review of access controls.
Example uses for RBAC in Azure
RBAC gives you granular control over resource access. You could use it, for example, to:
- Give a user full ownership access to all the resources within a specific resource group
- Let a user manage access to all virtual machines in a subscription
- Give an application permission to manage a specific resource type within a specific resource group
When you assign someone a role, that role becomes tied to their credentials and applies anywhere those credentials are used.
Take ShareGate Overcast, an app we built to help people view and manage their Azure resource costs more efficiently. Anyone with Azure credentials can log in to the app (see for yourself!), but only those who have the appropriate role assignment (in this case, Billing Reader or higher) will see any billing data.
In other words, if you're supposed to see it, you'll see it—without having to manually grant permission to the app. Because your role is tied to your credentials, it applies whether you're viewing data in the Azure portal or via a third-party interface.
How does RBAC work?
As mentioned earlier, RBAC is all about roles. To implement RBAC in your Azure environment, you need to create role assignments. (For a good rundown of how to manage RBAC via the Access management (IAM) blade in the Azure portal, see this documentation article.)
As its name suggests, a role assignment is created when you give someone or something a label (or role) that defines what resources or data can be accessed, and to what extent.
Three building blocks comprise a role assignment for RBAC: in Azure, they're known as security principal, scope, and role definition.
Security principal: who needs access?
A security principal in RBAC simply refers to the entity that's requesting resource access.
Why not just say user, then? Because you can assign permissions to other stuff, too. In Azure, this means:
- Users, people who have a profile in Azure Active Directory
- Groups, sets of users in Azure AD
- Service principals, which represent identities used by an application or service requiring resource access
- Managed identities, which are typically used to automate Azure authentication credentials (see this doc page for more about managed identities)
Scope: what needs to be accessed?
When building RBAC role assignments, scope defines which resources a given set of permissions applies to, and where those permissions stop applying. In Azure, role definitions can be scoped according to the following:
- Management group
- Resource group
If you need a refresher on the structure and hierarchy of an Azure environment (do management groups encompass subscriptions, or vice-versa?) this quick primer should clear things up.
Role definition: what type of access is required?
Here's where things can get granular. Role definitions, which are usually just called roles, refer to what a security principal is allowed to do to the resources within the specified scope.
Once again, NIST sums it up nicely:
A role is essentially a collection of permissions, and all users receive permissions only through the roles to which they are assigned, or through roles they inherit through the role hierarchy.
A good way to quickly understand how role definitions work on a deeper level is to take a look at their underlying structure.
There are a bunch of built-in roles in Azure, which range from simple (owner, contributor, reader—the usual) to specific. While standard roles such as owner and reader apply to all resource types, the other built-in roles are designed to apply to a specific service or resource type in Azure. Here are some examples.
|Owner||Gives you full access to all resources, including the right to delegate access to others.|
|Contributor||Lets you create and manage all types of Azure resources, but not grant access to others.|
|Reader||Lets you view existing Azure resources.|
|Cosmos DB Operator||Lets you manage Azure Cosmos DB accounts, but not access data in them. Prevents access to account keys and connection strings.|
|Virtual Machine Contributor||Lets you manage virtual machines, but not access to them, and not the virtual network or storage account they're connected to.|
See this doc page to peruse the full list of built-in roles. With so many of them available out of the box—and more being added all the time—chances are you'll find one that suits your scenario. If not, you can always create up to 5000 custom roles (via PowerShell, Azure CLI, or the REST API).
Role-based access control best practices
Because they represent such a critical aspect of security, RBAC policies should be implemented with caution and care. Here are a few things to keep in mind when designing an RBAC system:
- It's a good idea to follow the principle of least privilege when assigning roles to your users
- Fine-grained control is good, but don't get caught up in unnecessary complexity. If you're creating roles that only apply to one or two people in your entire organization, you're probably being a tad too specific. Simplicity means efficiency.
- On a similar note, don't get carried away with role assignments from the get-go. Start small with a few crucial roles, and scale as needed. There may be dozens of built-in roles, but that doesn't mean you need most of them!
- Test your roles before deploying them. At best, rolling out a half-baked role structure will have you dealing with a barrage of requests from users who need access to do their jobs; at worst, it could trigger a data breach.
- Roles don't have to be static. Review your role assignments periodically and make adjustments as needed.
Recommended read: [Infographic] 26 Azure best practices you may not have thought of, by Leigh Ryan
Role-based access control lets you manage access to your Azure resources according to a given scope (which resources the permission applies to), security principal (who, or what, needs access to that resource scope), and role (what is the security principal allowed to do to the resources in its defined scope).
Access management is an important part of any cloud governance strategy, a set of rules used to guide an organization's use of cloud resources in order to maintain things like data security and cost control. Implemented correctly, RBAC helps secure Azure environments without getting in the way of anyone who needs a certain level of access to do their job.
Get started with governance the right way!
Learn the ins and outs of cloud governance and how it can benefit your Azure environments in our new book, Modern Business Powered by Microsoft Azure: Governance.