In October, 2015 Microsoft announced its Azure Role Based Access Control (RBAC) feature has reached General Availability. The purpose of this feature is to allow organizations finer granularity when providing individuals and groups access to Azure resources and services.
RBAC allows for a central governance model where IT maintains overall control of the cloud environment, but can assign DevOps,or project, teams with the appropriate level of access for their set of services. Dushyant Gill, program manager at Microsoft, further explains “Using Azure RBAC, you can enable self-service management of cloud resources for your project teams while retaining central control over security sensitive infrastructure. For example, a common setup is to allow project teams to create and manage their own virtual machines and storage accounts, but only allow them to connect to networks managed by a central team.”
Microsoft uses a layered approach when assigning permissions to identities and groups as Ingrid Henkel, senior technical content developer at Microsoft, describes: “Each subscription in Azure belongs to one and only one directory, each resource group belongs to one and only one subscription, and each resource belongs to one and only one resource group.”
By using RBAC, access is now granted by assigning the appropriate RBAC role to users, groups and applications by using the correct scope. A user that only requires access to specific resource, can now get access to just that resource instead of having access to other resources within a subscription.
Historically, in the classic subscription model, administrators and co-administrators had full access to the Azure subscription. This often times resulted in corporate users having more access than required. In the new RBAC model, there are 3 basic built-in roles including:
- Owner has full access to all resources and the ability to delegate access
- Contributor can create and manage Azure resources but cannot delegate access
- Reader can only view existing Azure resources
Administrators in the classic model will now have Owner privileges in the RBAC model.
In addition to these basic built-in roles, Microsoft has published a complete list of built-in roles for specific products and services including SQL DB Contributor and Network Contributor as examples.
Permission inheritance is supported and is cascaded down from subscription to resource group to resource. If inherited permissions are applied at a resource group to an individual, that level of permissions will flow down to the resources that belong to that resource group. If permissions are inherited, they cannot be altered further down the permission stack and must be modified at the highest level.
RBAC permissions are not available in the classic portal but can be assigned in the new Azure portal. RBAC permissions can also be applied using Powershell or the Azure Command Line Interface.
For organizations that would like customized roles, they are able to do so by using RBAC command line tools. Much like built-in roles, custom roles can be assigned to users, groups and applications. In the following image, a custom rule called Virtual Machine Operator has been created and provides all of the necessary privileges, or actions, for someone to monitor and restart a virtual machine.
Image Source: https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/#custom-roles-in-azure-rbac
Microsoft has also provided a Change History Report which allows organizations to holistically view all of the permissions that have been granted or revoked in the past 90 days.
