Custom Roles for Azure RBAC

Back in September 2015, the RBAC (Role-Based Access Control) features of Azure became generally available, and yesterday the ability to create and assign custom roles was added. This is a continuing demonstration of the frequent improvements that we experience in the new cloud world. Now, by freeing us from the limitations of Azure’s built-in roles, we can for the first time freely define a role model which matches the organization of our IT operations.

Custom roles

A custom role is defined as a collection of permissions on one or more Azure Resource Providers. The resource providers of interest include Microsoft.Storage, Microsoft.Compute (e.g. for VMs) and Microsoft.Web (for websites). The permissions concern Actions – so to allow someone to read configurations of virtual machines you could assign, for example,


while to allow them to restart virtual machines, the following would apply:


The permissions can be assigned with the * wildcard, so


would allow all actions on all virtual machines. Finally, if only certain actions are not allowed, these can be defined by exclusion in so-called NotActions. Therefore with the Action


and the corresponding NotAction


you can define that a role allow all actions on virtual machines except Deallocation. (Note that if another role does allow Deallocation, an individual will be able to deallocate a VM – NotActions are just convenient ways of excluding an action from a role definition – they do not act as formal “Deny” statements.)

The next question is: how can I limit the scope of the role? Perhaps there is a group of people running a service involving a couple of VMs and a Web Site, and the Ops team in that group should have permissions only to those resources. In a custom role, you can define a scope – either for all resources in a Subscription, or for a Resource Group – which is the answer in this case. You would define a Resource Group, put the VMs and the Web Site into it, and publish the custom role to control those resources using the Resource Group as the scope for that role.

One last word – note that while the RBAC permissions discussed here allow (for example) an operator to create a new VM, you might want to restrict this creation to US-only regions. Such restrictions are available through the use of Policies – the subject of a future blog!

In summary, we now have the capability to create a role-based management model based on the real needs of the organization. Oxford Computer Group is ready to help you with the analysis and implementation of such a model. Contact us!