Microsoft Azure RBAC
What is Azure RBAC?
RBAC is role based access control. A bit of history to begin with might help understand this better. Before RBAC there were two basic roles in Azure- 1) service administrator and 2) co-admin for a subscription (of course this is outside of the EA roles like Account/Department admin)
Members who are part of these roles can do everything in a subscription right from VNet creation, VM creation and accessing logs and what not. Co-Admins are added from the management portal- manage.windowsazure.com and you can have more than one co-admin. Service Administrator is added by the Account Manager (added/managed from enterprise portal- ea.windowsazure.com). Members in both of these roles cannot see billing details (in the case of Enterprise Account) and for any tickets you open with Microsoft support, the email of service administrator is used for communication.
The distributed world of application development and infrastructure management requires much more than that. You may want few members to just take care of VMs, few others for Storage and so on. You may want to further assign different privileges within that. Like some could only view while others could create and so on. That basically is fine grained control. That’s what RBAC is all about. RBAC is not as complete as that as of this writing (02/01/2015) but it’s let’s say v1 towards that goal.
As of this writing you have three built-in roles (Owner, Contributor and Reader) available for assignment to Users, Groups and Services on Azure scopes: Subscription, Resource Group and Resources. You can manage the access using Azure portal, Command Line Tools & REST API for bulk operations.
What you can achieve today in RBAC is depicted in the graphic below-
The important architectural element worth noting is that these roles can actually be your IDMS roles (from your on premise AD which is federated). So that’s all for the introduction to Azure RBAC. I will further elaborate this with an example in a separate blog post.