In the previous guide, Understanding key difference between Azure ASM and Azure ARM, we saw what benefits we get with Azure ARM. Role-based Access Control is one of these benefits. In this guide, we will go through what role-based access control is, what are various built-in roles available in Azure and how can one create and apply custom roles to users.
Role-Based Access Control
In general, role-based access control (RBAC) is an approach to limiting access to systems and other resources in a network based on the roles assigned to individual users within an enterprise. Access here is the ability of an individual user to perform a specific task like create, view or modify resources. In RBAC, roles are created, modified and deleted easily. The access to specific resources or permissions required to perform certain operations is contained in the roles. Users are assigned different roles based on their job functions.
RBAC in Azure
In Azure, before the introduction of ARM deployment model, fine-grained access control to Azure resources was missing. In the traditional ASM model, different administrator level roles were defined including Global Administrator, Service Administrator, Billing Administrator, User Administrator, and Users. These roles cannot be used for fine-grained access control over Azure resources. Looking at other leading cloud competitors, Azure was missing this key feature. So with the introduction of the ARM deployment model, Azure introduced Role-Based Access Control over resources deployed in Resource Groups. This enables administrators to grant only required access to users to perform their job.
One Azure Active Directory is associated with each Subscription in Azure. Users, Groups, and Applications present in that Azure AD can manage resources present in that subscription. These access rights to the resources in the subscription can be assigned to users and groups in AD using Azure Portal, Azure PowerShell, Azure CLI and Azure Management APIs.
The scope of the assigned role can be an individual resource, a resource group or the whole subscription. A role assigned at a parent scope automatically grants access to the children contained within it. For example, a user with access to a subscription can manage all resource groups and resources present in that subscription. Similarly, a user with access to a resource group can manage all resources – like VMs, VNets, WebApps, etc. – present inside that resource group. The RBAC role that is assigned to a user controls what resources the user, group or application has access to.
The resource hierarchy in Azure can be shown as below:
As shown in the figure above, the resource hierarchy can be described as follows:
- Each subscription in Azure belongs to one and only one Azure AD
- Each resource group belongs to a single Azure subscription. However, one can change the subscription at a later stage if required.
- Each resource belongs to a single resource group
Azure has three basic built-in roles that apply to all resources:
Owner has full access to all resources present in that particular scope. Owner also has right to delegate access to other users.
Contributor, on the other hand, can create and manage resources on Azure but cannot manage access permissions to resources. A contributor cannot grant and invoke access to others.
Reader can only view the existing Azure resources without any permission to modify them.
When the Reader role is assigned to a group in Azure AD at a subscription level, members of that group can view all the resource groups and resources present in that subscription. Similarly, when a user is assigned the Contributor role to an application at a resource group level, he can manage all resources in that resource group, but not other resource groups in the subscription.
The other RBAC roles in Azure can be used for the management of specific Azure resources. For instance, roles like Website Contributor, VM Reader, VM Contributor, Storage Account Contributor, SQL Server Contributor, etc. can be used to manage individual resource types. The resource type is prefixed with the basic built-in roles. The VM Contributor role allows the user to create and manage VMs but does not give access to connected resources like Storage Account or Virtual Network. Similarly, VM Reader can only view the Virtual Machine and not modify its state (start/stop).
One constraint with Azure RBAC is that only the Azure Portal and the new Azure Resource Manager APIs support RBAC. Users that are assigned RBAC roles cannot use the Classic Deployment model and Azure Management Portal. However, Classic Subscription Administrators and co-admins do have full access to the Azure Management Portal, Azure Portal, and Resource Manager APIs. Classic Admins are assigned the Owner role at the Subscription level.
As discussed above, Owners and Contributors have full access to resources except that Contributors are unable to modify access to other users. The only exception is for the Reader role on some resource types. These resource types are:
- Azure App Service
- Azure Virtual Machines
Azure App Service
When a user is assigned read-only access to a single web app, some of the features might not work. A Web App contains many different interplaying resources. A typical resource group with a few websites will typically consist of an App Service Plan, Autoscale settings, Alert rules, App Insight components, etc. Thus granting access to just Web App might not serve the intended purpose. The following features will require WRITE access to App Service Plan:
- Viewing Web App’s pricing tier
- Scale configuration (VM size, no. of instances, autoscale settings)
- Quotas (CPU, Bandwidth, Storage)
- Autoscale settings
- Alert rules
- Application Insight components
- SSL Certificate and Bindings
- Web tests
Azure Virtual Machines
Virtual machines are dependent upon other resources like virtual networks, storage accounts, alert rules and Domain names. To access the following features in the VM blade, WRITE access is required at the resource (virtual machine) scope:
- IP Addresses
However, there are a few other resources that require WRITE access to both Virtual Machine as well as the Resource Group where the VM reside:
- Availability Set
- Load Balanced Set
- Alert Rules
If these tiles are disabled, you’ll need to ask your administrator to update your role to Contributor.
How to apply Built-in roles
Roles can be applied on resources using all the three ways; i.e. through the Azure Portal, using Azure PowerShell and using the Azure CLI. Here we shall apply VM Contributor role on existing VM using Azure Portal.
An Active Azure Subscription with access to Azure AD and an existing VM is required. If you don’t have a VM, you can create it. User creation is not mandatory. You can use existing users in your AD, if any.
Creating user in AD
- To create a new user in Azure AD, navigate to Azure AD and click on Add a user from Quick tasks. If Quick tasks box isn’t present, click on Users and Groups > All Users and click + New User.
- In the User blade, enter the Name and Username. Username should have a domain verified in your Azure AD. We are using the default domain name from our Azure AD. Directory role for that user should be User. Note down the password and click Create.
Assigning the role
As mentioned above, one can use an existing VM or create a VM in Azure if there are no existing VMs. Follow the steps below to apply VM Contributor role to the newly created user.
- Navigate to VM tab and click Access Control (IAM). Click on + Add.
- In the Add Permissions blade, select the role of VM Contributor and set the user as a newly- created user as shown below, and click Save.
Now to verify the new role, log in as a new user. As a VM Contributor, that user can manage Virtual Machines but can only view (read) associated resources like Virtual Network and Storage Account.
It may not be possible for built-in roles to satisfy our access management requirements. Also, there is no way one can change the definition of the built-in roles. So in that case, Azure allows us to create custom roles that can suit our access needs. Custom roles can easily be created using Azure PowerShell, the Azure CLI, and the REST API. Custom roles are assigned to users, groups, and applications at resources and resource group scopes. These custom roles are stored in the Azure AD tenant and can be shared across all the subscriptions that use the same AD tenant. Each tenant can have up to 2000 custom roles.
Anatomy of a Role
Get-AzureRmRoleDefinition "Virtual Machine Contributor" OR
Get-AzureRmRoleDefinition "Virtual Machine Contributor" | FL Actions, NotActions
it would look as shown below:
The Actions property specifies the list of allowed actions for a user or group on a particular resource of the resource group. The wildcard characters can also be used in this property. To view a list of allowed actions under Actions property for a particular role using PowerShell, use the following cmdlet:
(Get-AzureRmRoleDefinition “Virtual Machine Contributor”).Actions
The action can be of two types which define what operations you can perform on a specified resource. They are:
Read: The Read action enables the user or group to perform GET operations
Write: The Write action allows the user or group to perform PUT, POST, PATCH and DELETE operations
In a custom role, the Action property specifies the list of operations to which the role grants access. The collection of operation strings of the form Microsoft.<ProviderName>/<ChildResourceType>/<action> identifies operations permitted to a user on Azure resources. For instance:
Microsoft.Web/sites/restart/Action grants permission to restart WebApps.
Operation strings can contain wildcard character like * which will grant access to all operations that match the operation string. For example,
Microsoft.Compute/virtualMachines/* grants access to perform all operations on VM and its child resources.
The NotActions property specifies the list of actions that are excluded from the allowed actions. Users aren’t allowed to perform the actions listed in NotActions property. The list of non-allowed actions under NotActions can be listed found using the following PowerShell cmdlet:
(Get-AzureRmRoleDefinition “Virtual Machine Contributor”).NotActions
The AssignableScope property specifies the list of subscriptions where the selected role is applicable. By default, the built-in role will be available in all the subscriptions that reside in your Azure AD tenant. The list contains Subscription IDs and not subscription names. This property of custom roles can also control who can view, modify or delete the role. By default, Owners can create, modify or delete custom roles.
Now we know the anatomy of the custom role, let’s get going by creating a custom role and assigning it to a user.
Azure Subscription, Azure PowerShell, and a simple text editor are good to get started. Azure ARM Module in PowerShell is required for ARM deployments. For details on how to configure PowerShell for ARM deployments, click here.
Creating a custom role and assigning it to a user
To create a custom role, we shall follow three generalized steps:
- Search for a built-in role whose permissions are closest to our requirements
- Export its definition and modify the permissions as per our requirement
- Create a custom role using updated definition
Get-AzureRmRoleDefinition "Virtual Machine Contributor" | ConvertTo-JSON | Out-File C:\Users\armank\Desktop\export-role.json
3. Open this JSON file in any text editor
4. Let’s start by removing unwanted properties. So, we will remove the Id and IsCustom properties as they’re not required in a custom role. We will then edit the Name and Description for the custom role.
5. Next, we will remove all existing rules in Actions property. We want to grant read access to all Compute, Network and Storage resource types. So we will add the following lines:
These permissions are enough to give read access to all sub-services, like Availability Sets, Scale Sets, Load Balancers, Network Security Group, Public IP Addresses, etc. We can further fine-grain this read access by specifying individual resource types, as below:
So, using the above set of lines, we give read access to the individual resource set. We add Microsoft.Authorization/*/read permission so that this new role will allow the user to view RBAC roles and role assignments. Also, we added the Microsoft.Resources/subscriptions/resourceGroups/read permission for the user to view Resource Groups.
6. The next step is to add permission to add start and restart machines. So we will add the following lines to allow a user to start and restart VM:
7. Add the Subscription IDs in AssignableScope for our role to be present in specified Subscriptions. To get the list of available subscriptions, use the following cmdlet:
8. We will not add anything in NotActions. The finalized role file should look as shown below:
9. Save this file and we will use it to create a new role definition using the following command:
New-AzureRmRoleDefinition –InputFile C:\Users\armank\Desktop\export-role.json
10.Log in to the Azure Portal. Navigate to IAM in the VM blade (uUse the previously -created VM and User). Select the user and click on Remove.
11.Click on + Add. Select the Role as Azure Intern, select the user we created, and click Save.
12.On the IAM blade, the new user will be assigned the custom role of Azure Intern. Log in as the new user and verify it.
Thus, we created a new custom role and assigned it to the user. To figure out action strings for any resources, use the following string by modifying the ChildResourceType in the following command:
Get-AzureRmProvider Operation – OperationSearchString Microsoft.<ProviderName>/<ChildResourceType>/* | FT Operation