I haven’t written here in a while, but I promise I have a good reason.
I started a new job mid-October as a Microsoft Certified Trainer at a local tech college, teaching about Microsoft’s cloud platform, Microsoft Azure.
I’ve tried writing some posts to put here but frankly it’s been so hectic and it was difficult juggling between the two.

Anyway, I thought, why not come back with a lightweight topic that doesn’t require me to learn something from scratch? Hence I decided to write a blog post about a question one of my students asked me.
Let’s start!

If you’ve ever been an Azure Administrator you probably noticed that a lot of things (and I mean a lot) are represented in JSON format. ARM templates, policy definitions, logs, and role definitions. What are those anyway?

Role Definitions

At their core, role definitions are a collection of permissions that can be assigned to a user. As mentioned before they are written in JSON. Let’s take a look.

In this picture we can identify that the role definition for the role “Contributor” (as do all of the other role definitions) consists of 5 distinct keys. We’re going to break them down soon, but first…

How Permissions Are Specified

Permissions in Azure are written in a very distinct format. first, we write the resource provider name, which starts with the name of the company and then the name of the product/family. For example, the resource provider which enables us to create VMs in Azure is called Microsoft.Compute.

You can see that in the screenshot above the permission starts with “Auth”, this is done to shorten the string, the actual value that should be there is Microsoft.Authorization.

After specifying the provider, we specify the type of the resource, followed by the action we would like to allow/deny. If we continue with the VMs example, a permission could look like any of the following:

Microsoft.Compute/VirtualMachines/read
Microsoft.Compute/VirtualMachines/*

Yes, We can specify wildcard permissions, effectively granting/denying all permissions on a resource type! In the above example, the first line will grant read permission to VMs, while the second line will grant the user permissions to perform any action on VMs within the assigned scope.

Actions & NotActions

the Actions field can hold an array of actions the role will allow a person to do. In this case, there’s an asterisk which you might already interpret as a wildcard. An asterisk in the Actions field means the user will be able to perform all actions.

The NotActions field counteracts the Actions field which basically means “This user can do anything BUT the permissions listed in the NotActions field.
In the case of the contributor role, this means the role assignee will be able to do everything except deal with permissions. The user will be able to manage the resource but not give/take/change other people’s permissions over it.

DataActions and NotDataActions

“Well”, you might say, “If we have Actions & NotActions why do we need 2 more fields with similar names?”. Fantastic question, I say!

When referring to DataActions and NotDataActions, they work the same way as Actions and NotActions, but pertain to actions involving data rather than administration.

For example, to give permissions on Blob containers, we will specify the corresponding permissions (Microsoft.Storage/storageAccounts/blobServices/containers/*) under the Actions field.

To give access to the Blobs themselves (which are essentially files), we will specify the corresponding permissions (Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*) under DataActions.

Assignable Scopes

The AssignableScopes field is used to specify, well, which scopes the role can be assigned within. The format is somewhat similiar to how we specify the permissions themselves, but a little different. First of all, it starts with a slash. In the screenshot above, you can see there is only a slash under the AssignableScopes field, meaning this role can be assigned within any scope. If we’d like to specify a specific scope, we can do that. Here are a few examples taken from Microsoft’s documentation (No need to reinvent the wheel eh?).

There you have it kids, Azure Role Definitions Demystified!