Azure Role-Based Access Control (RBAC) As Fast As Possible

Role-based access control (RBAC) is the centerpiece of any robust, distributed system. The ability to use RBAC allows users to be decoupled from the systems that they use by assigning roles to an individual, then defining privileges based on roles rather than trying to assign people permissions directly. This allows systems administrators and security personnel to more easily manage roles.

Azure broadly defines three different roles: Reader, Contributor, and Owner. These roles apply to Subscriptions, Resource Groups, and most all Resources on Azure. Each role has distinct characteristics that impact what a user can do at a given level, but in general, they are straightforward:

Readers: Readers on Azure can see things in a Resource, Resource Group, or Subscription, but cannot change anything in any of these. This role is useful for people who are typically in an observer type role, such as an auditor. This ensures that people can validate settings, but also ensures that nothing can be changed by these users.

Contributor: Contributors can do pretty much anything a Reader can do, but with the added ability to change resources. Changing resources implies being able to alter the technical behaviors of the resource such that they function differently, depending on the changes. Also, within Resource Groups, Subscriptions, and some Resources with sub-resources, Contributors can create new resources. This is important to remember when assigning Contributor roles to users because it can significantly alter the billing when a Contributor makes changes.

Owner: An Owner can do everything a Contributor can do with one additional ability, and that is the ability to assign roles to a Subscription, Resource Group, or Resource, depending on where the ownership role is set. Assigning permissions means that an Owner can assign others as Readers, Contributors, and Owners, so it is a very powerful role within the context of Azure. As a rule, then, this role should be used sparingly.

Roles in Azure are also inherited, meaning that within the hierarchy of resources, if a parent Resource Group, Subscription, or Resource has a user with an assigned role, then the resources within that Resource Group, Subscription, or Resource are implicitly assigned the same permissions, unless that are explicitly denied access. The basic structure of Azure Inheritance starts at the Subscription, then goes to the Resource Group, then down to the Resources themselves. This means that that if a user is an Owner of Resource Group, then that user is also by default an Owner of all the Resources in that Resource Group as well.

Assigning permissions in Azure first requires that a user exists in Azure AD. There are a number of ways to create users in Azure AD – either through a manual process, integration with Microsoft Accounts (MSA), using Azure AD Connect, or using federation. Once the user is in Azure AD though, he or she can be assigned permissions in Azure using the I AM blade that is present on every resource. Within this blade, there is a list of users, their assigned permissions, then how they were assigned those permissions under the Scope, such as being inherited. From there, permissions can easily be modified.

While these three basic roles will cover a broad range of use cases for roles, Azure also has custom roles at the Resource level that can be assigned for very specific tasks, such as Database Backups, or VM Shutdowns. These kinds of roles are useful automation and for users who fulfill those roles. For simplicity, prefer the three basic roles. And if these don’t work, you can always use more specific roles.