If the Azure built-in roles don't meet the specific needs of your organization, you can create your own custom roles. Just like built-in roles, you can assign custom roles to users, groups, and service principals at management group, subscription, and resource group scopes.
Custom roles can be shared between subscriptions that trust the same Microsoft Entra tenant. There is a limit of 5,000 custom roles per tenant. (For Microsoft Azure operated by 21Vianet, the limit is 2,000 custom roles.) Custom roles can be created using the Azure portal, Azure PowerShell, Azure CLI, or the REST API.
Steps to create a custom role
Here are the basic steps to create a custom role.
Determine the permissions you need.
When you create a custom role, you need to know the actions that are available to define your permissions. Typically, you start with an existing built-in role and then modify it for your needs. You will add the actions to the Actions or NotActions properties of the role definition. If you have data actions, you will add those to the DataActions or NotDataActions properties.
Once you have your custom role, you have to test it to verify that it works as you expect. If you need to make adjustments later, you can update the custom role.
How to determine the permissions you need
Azure has thousands of permissions that you can potentially include in your custom role. Here are some methods that can help you determine the permissions you will want to add to your custom role:
Azure services expose their functionality and permissions through resource providers. For example, the Microsoft.Compute resource provider supplies virtual machine resources and the Microsoft.Billing resource provider supplies subscription and billing resources. Knowing the resource providers can help you narrow down and determine the permissions you need for your custom role.
When you create a custom role using the Azure portal, you can search for permissions by keyword. For example, you can search for virtual machine or billing permissions. You can also download all of the permissions as a CSV file and then search this file. This search functionality is described in Create or update Azure custom roles using the Azure portal.
Custom role example
The following shows what a custom role looks like as displayed using Azure PowerShell in JSON format. This custom role can be used for monitoring and restarting virtual machines.
The following table describes what the custom role properties mean.
Property
Required
Type
Description
Name roleName
Yes
String
The display name of the custom role. While a role definition is a management group or subscription-level resource, a role definition can be used in multiple subscriptions that share the same Microsoft Entra tenant. This display name must be unique at the scope of the Microsoft Entra tenant. Can include letters, numbers, spaces, and special characters. Maximum number of characters is 512.
Id name
Yes
String
The unique ID of the custom role. For Azure PowerShell and Azure CLI, this ID is automatically generated when you create a new role.
IsCustom roleType
Yes
String
Indicates whether this is a custom role. Set to true or CustomRole for custom roles. Set to false or BuiltInRole for built-in roles.
Description description
Yes
String
The description of the custom role. Can include letters, numbers, spaces, and special characters. Maximum number of characters is 2048.
Actions actions
Yes
String[]
An array of strings that specifies the control plane actions that the role allows to be performed. For more information, see Actions.
NotActions notActions
No
String[]
An array of strings that specifies the control plane actions that are excluded from the allowed Actions. For more information, see NotActions.
DataActions dataActions
No
String[]
An array of strings that specifies the data plane actions that the role allows to be performed to your data within that object. If you create a custom role with DataActions, that role can't be assigned at management group scope. For more information, see DataActions.
NotDataActions notDataActions
No
String[]
An array of strings that specifies the data plane actions that are excluded from the allowed DataActions. For more information, see NotDataActions.
AssignableScopes assignableScopes
Yes
String[]
An array of strings that specifies the scopes that the custom role is available for assignment. Maximum number of AssignableScopes is 2,000. For more information, see AssignableScopes.
Permission strings are case-insensitive. When you create your custom roles, the convention is to match the case that you see for permissions in Azure resource provider operations.
Wildcard permissions
Actions, NotActions, DataActions, and NotDataActions support wildcards (*) to define permissions. A wildcard (*) extends a permission to everything that matches the action string you provide. For example, suppose that you wanted to add all the permissions related to Azure Cost Management and exports. You could add all of these action strings:
Instead of adding all of these strings, you could just add a wildcard string. For example, the following wildcard string is equivalent to the previous five strings. This would also include any future export permissions that might be added.
Microsoft.CostManagement/exports/*
Note
It's recommended that you specify Actions and DataActions explicitly instead of using the wildcard (*) character. The additional access and permissions granted through future Actions or DataActions may be unwanted behavior using the wildcard.
Who can create, delete, update, or view a custom role
Just like built-in roles, the AssignableScopes property specifies the scopes that the role is available for assignment. The AssignableScopes property for a custom role also controls who can create, delete, update, or view the custom role.
Task
Action
Description
Create/delete a custom role
Microsoft.Authorization/ roleDefinitions/write
Users that are granted this action on all the AssignableScopes of the custom role can create (or delete) custom roles for use in those scopes. For example, Owners and User Access Administrators of management groups, subscriptions, and resource groups.
Update a custom role
Microsoft.Authorization/ roleDefinitions/write
Users that are granted this action on all the AssignableScopes of the custom role can update custom roles in those scopes. For example, Owners and User Access Administrators of management groups, subscriptions, and resource groups.
View a custom role
Microsoft.Authorization/ roleDefinitions/read
Users that are granted this action at a scope can view the custom roles that are available for assignment at that scope. All built-in roles allow custom roles to be available for assignment.
Note
Even if a role is renamed, the role ID does not change. If you are using scripts or automation to create your role assignments, it's a best practice to use the unique role ID instead of the role name. Therefore, if a role is renamed, your scripts are more likely to work.
Find role assignments to delete a custom role
Before you can delete a custom role, you must remove any role assignments that use the custom role. If you try to delete a custom role with role assignments, you get the message: There are existing role assignments referencing role (code: RoleDefinitionHasAssignments).
Here are steps to help find the role assignments before deleting a custom role:
The following list describes the limits for custom roles.
Each tenant can have up to 5000 custom roles.
Microsoft Azure operated by 21Vianet can have up to 2000 custom roles for each tenant.
You cannot set AssignableScopes to the root scope ("/").
You cannot use wildcards (*) in AssignableScopes. This wildcard restriction helps ensure a user can't potentially obtain access to a scope by updating the role definition.
You can have only one wildcard in an action string.
You can define only one management group in AssignableScopes of a custom role.
Azure Resource Manager doesn't validate the management group's existence in the role definition's AssignableScopes.
Custom roles with DataActions can't be assigned at the management group scope.
You can create a custom role with DataActions and one management group in AssignableScopes. You can't assign the custom role at the management group scope itself; however, you can assign the custom role at the scope of the subscriptions within the management group. This can be helpful if you need to create a single custom role with DataActions that needs to be assigned in multiple subscriptions, instead of creating a separate custom role for each subscription.
To create a custom role using the command line, you typically use JSON to specify the properties you want for the custom role. Depending on the tools you use, the input and output formats will look slightly different. This section lists the input and output formats depending on the tool.
Azure PowerShell
To create a custom role using Azure PowerShell, you must provide following input.
To create or update a custom role using Azure CLI, you must provide following input. This format is the same format when you create a custom role using Azure PowerShell.
To create or update a custom role using the REST API, you must provide following input. This format is the same format that gets generated when you create a custom role using the Azure portal.