The Azure Service Management REST API (ASM) provides the definitive way to manage Azure resources. The production Azure Portal, the Azure PowerShell cmdlets, the cross-platform CLI and the Azure Management Libraries for .NET are all built on top of the ASM. However, the ASM was initially developed more than 5 years ago and is now showing signs of age. Most notably, it does not support desired-state configuration and it does not support role-based access control (RBAC). ASM supports authentication with either X.509 certificates or Azure Active Directory (AAD).
The Azure Resource Manager REST API (ARM) is being developed to replace ASM as the definitive way to manage Azure resources. ARM supports both desired-state configuration and RBAC, while also providing a pluggable model allowing new Azure services to be cleanly integrated. The preview Azure Portal and the ARM mode of the Azure PowerShell cmdlets both use ARM. AAD is the only authentication method supported by ARM.
ARM introduces the concept of a resource group which is a collection of individual Azure resources. A resource group is associated with a specific Azure region but may contain resources from more than one region. ARM supports the use of a parameterized resource group template file that can be used to stamp out one or more resource groups along with their individual resources. The deployment of a resource group uses desired-state configuration – that is, ARM ensures that the resources are deployed in accordance with the appropriately parameterized template file for the resource group. Although resource providers exist for many types of Azure resource, the resource providers for some critical Azure resources are not currently available for use in the Azure PowerShell cmdlets.
ARM supports role-based access control (RBAC), and this support is expressed in both the preview Azure Portal and the ARM mode of the Azure PowerShell cmdlets. ARM provides some core roles – Owner, Contributor and Reader – and individual resource providers support additional resource-specific roles such as Search Service Contributor and Virtual Machine Contributor. Custom roles are not yet supported. Each role is specified by a set of Actions and NotActions: a user (or user in a group) assigned to the role is permitted to perform the actions in the Actions set; and a user (or group) assigned to the role is forbidden from performing any action in the NotActions set.
RBAC is implemented in a hierarchical fashion with a scope reaching from subscription, down through resource groups, to individual resources. A user or group is added to a role at a specified role scope. For example, an AAD user or group can be added to some role for a deployed resource group and is then permitted to perform a constrained set of actions on that resource group and all resources in it.
A user is allowed to perform only those actions for which appropriate rights have been conferred. For example, a user assigned to no role other than Contributor for a specific resource group is unable to perform any action at the subscription level or in other resource groups. In fact, when using the preview Azure Portal this user is unable to even view other resource groups and their contents.
The 3 core roles are:
- Owner - full management rights
- Contributor - full management rights except for user management
- Reader – view resource rights
The Contributor role has the following Actions:
The Contributor role has the following NotActions:
These Actions and NotActions indicate that the Contributor role is permitted to do any action except modify the authorization rights of other users.
The following resource-type roles are provided currently:
- API Management Service Contributor
- Application Insights Component Contributor
- BizTalk Contributor
- ClearDB MySQL DB Contributor
- Data Factory Contributor
- DocumentDB Account Contributor
- Intelligent Systems Account Contributor
- New Relic APM Account Contributor
- Redis Cache Contributor
- SQL DB Contributor
- SQL Security Manager
- SQL Server Contributor
- Scheduler Job Collections Contributor
- Search Service Contributor
- Storage Account Contributor
- User Access Administrator
- Virtual Machine Contributor
- Virtual Network Contributor
- Web Plan Contributor
- Website Contributor
Each of these supports resource-type specific actions.
For example, the Virtual Machine Contributor role has the following Actions:
The Virtual Machine Contributor role has no NotActions.
The above permission set indicates that the Virtual Machine Contributor role is permitted to perform those tasks required to manage VMs – such as creating a VM - but is not permitted to perform tasks on other resources - such as creating a storage account.
The full set of currently provided roles and the Actions and NotActions they support is documented here.
Azure PowerShell cmdlets
The Azure PowerShell cmdlets have two modes: the default Azure Service Management mode; and the Azure Resource Manager mode. On opening an Azure PowerShell shell the ASM mode is selected. The following Azure PowerShell cmdlet must be used to switch to ARM mode:
- Switch-AzureMode -Name AzureResourceManager
The Azure PowerShell cmdlets provides the following cmdlets to manage role assignments:
- Get-AzureRoleAssignment – retrieve the roles assigned to a user
- Get-AzureRoleDefinition – list the Actions and NotActions for a role
- New-AzureRoleAssignment – assign a role assignment to a user or group
- Remove-AzureRoleAssignment – remove a role assignment from a user or group
Get-AzureRoleAssignment returns the role and scope assignments for users and groups. Get-AzureRoleDefinition returns the Actions and NotActions for roles. New-AzureRoleAssignment assigns a user or group to a role at the specified role scope. Remove-AzureRoleAssignment removes a role assignment for a user or group. For example, the following adds a user to the Reader role at the specified scope:
- New-AzureRoleAssignment -UserPrincipalName firstname.lastname@example.org -RoleDefinitionName Reader -Scope /subscriptions/SOME-GUID/resourceGroups/SomeResourceGroupName
Were –Scope not specified the role assignment would have applied to the entire subscription.
David Ebbo has a post in which he shows how to create and use a service principal, rather than a simple user, for RBAC with the ARM. Dushyant Gill has a post in which he shows how to use a PowerShell module he wrote to provide richer access to the RBAC information for a subscription.
Preview Azure Portal
The preview Azure Portal supports RBAC, and provides a UI for adding users and groups to roles at arbitrary role scope from subscription down to individual resource. The UI is exposed at the subscription scope, resource group scope and resource scope - and allows the addition and deletion of users and groups from AAD into any of the currently valid roles.
The following shows the access-control "part" that displays that is displayed at resource group scope or resource scope:
Right-clicking on the part brings up a pane allowing users and groups to be added to roles for the resource group or resource. The following image shows the users and the roles to which they have been assigned for a resource named Centralia: