Welcome to “A Quick Introduction to Role-Based Access Control”. To get the most from this course, you should already have some basic experience using Azure. If you don’t, then you can take our “Overview of Azure Services” course.

Azure Active Directory can authenticate users, meaning it identifies who they are, but it doesn’t know what they should be allowed to do in Azure. In other words, it doesn’t handle authorization. That’s managed by a separate system called role-based access control (or RBAC).

For example, suppose you have three groups of people who need access to the resources in an Azure subscription. End-users need access to everything, but they shouldn’t have the ability to modify anything. Developers need to be able to access and modify everything. Administrators need to be able to access and modify everything, and they also need to be able to grant or deny access to other users.

You could do this by assigning different roles to the three groups. You would assign the Reader role to end-users, the Contributor role to developers, and the Owner role to administrators. These roles are sets of permissions that can be easily assigned to users or groups.

I should mention that this is a pretty unrealistic example, though, because your requirements will almost never be this simple. A more likely scenario would include requirements like these:

• People in the Technical Marketing department need read access to the blob data in Storage Account 1 and write access to the blob data in Storage Account 2.
• People in the Product Development for Marketing team need full access to all of the virtual machines in Resource Group 1.

To grant these permissions, you need to use fine-grained roles. So, instead of granting the Reader or Contributor role for the entire subscription to people in the Technical Marketing department, you’d grant them the Storage Blob Data Reader role for Storage Account 1 since they only need read access for that one and the Storage Blob Data Contributor role for Storage Account 2 since they only need write access for that one.

For the second requirement, you’d grant people in the Product Development for Marketing team the Virtual Machine Contributor role for Resource Group 1.

Notice that in these examples, not only would you be assigning fine-grained roles, but you’d also be limiting them to particular resource groups or resources. This is referred to as setting the scope. You can do this at one of four levels: management group, subscription, resource group, or resource. If you set the scope at any of the upper levels, then the permissions will be granted for everything underneath it. For example, if you grant the Virtual Machine Contributor role for Resource Group 1, then you’re also granting that role for all of the resources in Resource Group 1.

So how would it work if you granted a user the Reader role at the subscription level and the Contributor role at the resource group level? Would the Reader role at the subscription level override the Contributor role at the resource group level? No, it doesn’t work that way. The roles are additive, meaning that the user would have both roles at the resource group level, so, effectively, they would have the Contributor role at that level because it has all of the Reader permissions plus more.

Not only can you assign roles to users and groups, but you can also assign them to Azure service instances. Why would you want to do that? Well, a typical example would be: you have an application that runs on a virtual machine that needs to read data from and write data to an Azure SQL Database instance called SQL Database 1. So the application would need to be granted the permissions to do that. However, you wouldn’t be able to grant permissions to the application itself, but you could grant them to the virtual machine instance that the application is running on. You could assign the SQL DB Contributor role for SQL Database 1 to the virtual machine.

So how exactly would you do that? Well, you’d create what’s called a managed identity for the virtual machine. When you enable this feature on a VM, it creates an identity in Azure Active Directory. Then you can assign one or more roles to the identity. So you’d actually be assigning the SQL DB Contributor role for SQL Database 1 to the managed identity for the virtual machine. This would allow the application running on the VM to access the SQL Database instance.

Regardless of which type of identity you want to assign a role to, the way you do it is to go into the “Access control” pane of the Azure resource you want to grant access to. For example, if you wanted to assign a user the Virtual Machine Contributor role for VirtualMachine1, you’d go into VirtualMachine1 in the Azure portal, then select “Access control” from the menu, then click the “Role assignments” tab, add a role assignment, select the Virtual Machine Contributor role, and find the user you want to assign it to. And it’s done.

So far, all of the roles I’ve mentioned have been built-in roles. That is, they’re roles that have been predefined by Microsoft. Each role is actually a bundle of permissions. For example, the Storage Blob Data Reader role includes one permission to view Storage containers and another permission to view the blobs inside the containers. Some roles include dozens of different permissions. Microsoft provides these built-in roles so you don’t have to figure out all of the permissions that you need to assign.

But what if you want to assign a set of permissions that’s different from what’s in any of the built-in roles? For example, what if you wanted to assign permission to view Storage containers but not to read the blobs inside those containers? You could do that by creating a custom role that contained only that permission. Of course, you’d need to have permission to create custom roles first. As you can see, there are permissions for everything.

And that’s it for this quick introduction to role-based access control. Please give this course a rating, and if you have any questions or comments, please let us know. Thanks!