Resource manager is your infrastructure team in the cloud. In my last post, I talked about Tags and Templates. In this post, my last one on the Resource Manager I will talk about Role-Based Access Control (“RBAC”).
RBAC in Azure allows you to wall-off specific duties for your DevOps team. With RBAC you can grant specific access to specific users, giving them just enough access to perform their tasks.
The RBAC comes with a number of built-in roles that can simply be assigned. Currently, you cannot modify these, but in the next release of Azure RBAC, you will be allowed to define your own custom roles by choosing from a list of pre-defined actions.
There are three basic roles built into RBAC: Owner, Contributor, and Reader. Those assigned the role of Owner have full access, as well as the ability to create new access for others. Those assigned the role of Contributor are able to create and manage any Azure resource, but are unable to create new access rolls for others. Those with Reader access can view the existing resources and nothing else.
Azure RBAC gives more control over authorizations than classic administration tools. The system is based on resource hierarchy and access inheritance. Access that is granted at parent scopes is inherited at child scopes. With this system, a contributor can be given access to a specific resource group without simultaneously granting access to other resource groups within the same subscription.
Adding access is a simple point and click process.
From the Users blade, you:
- Click the Add icon,
- Select the role to be assigned,
- Select the user, group, or application you want to grant access to, and
- Select the user, group or application you want to have the defined access.
Easy as 1, 2, 3 (4)!
If you prefer managing from Azure PowerShell, RBAC commands can be used there. Detailed examples of how to do this can be found here: https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-manage-access-powershell/
Any access changes that are made are automatically logged in Azure events. Details such as who granted or revoked which access and for whom, are all kept. The log can be exported for reporting using PowerShell, Azure CLI, or even to a spreadsheet.
If non of the built-in roles in RBAC suits your particular needs, you can create a custom role. The custom role can be built from the ground up by adding Actions to a list. Conversely, if an existing role covers your needs but there are some areas you want to restrict, “NotActions” can be used to exclude specific operations.
Microsoft is working hard to compete in the cloud. Their efforts are reflected in the tools they have created to make your life in the cloud just that much easier.