Настраиваемые роли Azure
Если встроенные роли Azure не соответствуют потребностям вашей организации, вы можете создать собственные настраиваемые роли. Как и встроенные роли, ваши пользовательские роли можно назначать пользователям, группам и субъектам-службам на уровне группы управления, подписки и группы ресурсов.
Пользовательские роли можно совместно использовать между подписками, которые доверяют одному клиенту Microsoft Entra. Существует ограничение в 5 000 пользовательских ролей для каждого клиента. (Для Microsoft Azure, управляемой 21Vianet, ограничение составляет 2000 пользовательских ролей.) Пользовательские роли можно создавать с помощью портал Azure, Azure PowerShell, Azure CLI или REST API.
Процедура создания пользовательской роли
Ниже представлены основные шаги создания настраиваемой роли.
Определите нужные разрешения.
При создании настраиваемой роли необходимо знать действия, доступные для определения разрешений. В общем случае вы начинаете с существующей встроенной роли и видоизменяете ее под свои потребности. Вы добавите действия в
Actions
определение роли илиNotActions
свойства. Если у вас есть действия с даннымиDataActions
, вы добавите их в свойства илиNotDataActions
свойства.Дополнительные сведения см. в следующем разделе — Определение нужных разрешений.
Выберите способ создания настраиваемой роли.
Настраиваемые роли можно создать с помощью портала Azure, Azure PowerShell, Azure CLI или REST API.
Создайте настраиваемую роль.
Проще всего сделать это на портале Azure. Инструкции по созданию настраиваемой роли с помощью портала Azure см. в статье Создание или изменение настраиваемых ролей Azure с помощью портала Azure.
Проверьте настраиваемую роль.
Создав пользовательскую роль, нужно проверить правильность ее работы. Если позже потребуется корректировка, вы можете обновить пользовательскую роль.
Определение нужных разрешений
В Azure есть тысячи разрешений, которые потенциально можно включить в настраиваемую роль. Ниже приведены некоторые методы, которые могут помочь определить разрешения, добавляемые в настраиваемую роль:
Просмотрите существующие встроенные роли.
Может понадобиться изменить существующую роль или объединить разрешения, используемые в нескольких ролях.
Составьте список служб Azure, к которым нужно предоставить доступ.
Определите поставщики ресурсов, сопоставляемые со службами Azure.
Службы Azure предоставляют свои функции и разрешения с помощью поставщиков ресурсов. Например, поставщик ресурсов Microsoft.Compute предоставляет ресурсы виртуальной машины, а поставщик ресурсов Microsoft.Billing предоставляет ресурсы подписки и выставления счетов. Знание поставщиков ресурсов поможет сузить и определить разрешения, нужные для настраиваемой роли.
При создании настраиваемой роли с помощью портала Azure можно также определить поставщиков ресурсов, выполнив поиск по ключевым словам. Эта функция поиска описана в статье Создание или изменение настраиваемых ролей Azure с помощью портала Azure.
Выполните поиск доступных разрешений, чтобы найти разрешения, которые нужно включить.
При создании настраиваемой роли с помощью портала Azure можно выполнять поиск разрешений по ключевому слову. Например, можно выполнить поиск разрешений длявиртуальной машины или выставления счетов. Можно также скачать все разрешения в виде CSV-файла, а затем выполнить поиск в этом файле. Эта функция поиска описана в статье Создание или изменение настраиваемых ролей Azure с помощью портала Azure.
Пример пользовательской роли
Ниже показано, как выглядит настраиваемая роль, отображаемая в формате JSON с помощью Azure PowerShell. Эта пользовательская роль позволяет выполнять мониторинг и перезапуск виртуальных машин.
{
"Name": "Virtual Machine Operator",
"Id": "88888888-8888-8888-8888-888888888888",
"IsCustom": true,
"Description": "Can monitor and restart virtual machines.",
"Actions": [
"Microsoft.Storage/*/read",
"Microsoft.Network/*/read",
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Authorization/*/read",
"Microsoft.ResourceHealth/availabilityStatuses/read",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Insights/alertRules/*",
"Microsoft.Insights/diagnosticSettings/*",
"Microsoft.Support/*"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/subscriptions/{subscriptionId1}",
"/subscriptions/{subscriptionId2}",
"/providers/Microsoft.Management/managementGroups/{groupId1}"
]
}
Ниже показано, как отображается эта же роль с помощью Azure CLI.
[
{
"assignableScopes": [
"/subscriptions/{subscriptionId1}",
"/subscriptions/{subscriptionId2}",
"/providers/Microsoft.Management/managementGroups/{groupId1}"
],
"description": "Can monitor and restart virtual machines.",
"id": "/subscriptions/{subscriptionId1}/providers/Microsoft.Authorization/roleDefinitions/88888888-8888-8888-8888-888888888888",
"name": "88888888-8888-8888-8888-888888888888",
"permissions": [
{
"actions": [
"Microsoft.Storage/*/read",
"Microsoft.Network/*/read",
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Authorization/*/read",
"Microsoft.ResourceHealth/availabilityStatuses/read",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Insights/alertRules/*",
"Microsoft.Insights/diagnosticSettings/*",
"Microsoft.Support/*"
],
"dataActions": [],
"notActions": [],
"notDataActions": []
}
],
"roleName": "Virtual Machine Operator",
"roleType": "CustomRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
]
Свойства пользовательской роли
В следующей таблице показано, что означают свойства настраиваемой роли.
Свойство | Обязательное поле | Type | Описание |
---|---|---|---|
Name roleName |
Да | Строка | Отображаемое имя пользовательской роли. Хотя определение роли является группой управления или ресурсом уровня подписки, определение роли можно использовать в нескольких подписках, которые совместно используют один клиент Microsoft Entra. Отображаемое имя должно быть уникальным в области клиента Microsoft Entra. Может содержать буквы, цифры, пробелы и специальные знаки. Максимальное число символов — 512. |
Id name |
Да | Строка | Уникальный идентификатор настраиваемой роли. Для Azure PowerShell и Azure CLI этот идентификатор формируется автоматически при создании роли. |
IsCustom roleType |
Да | Строка | Указывает, является ли эта роль настраиваемой. Задайте значение true или CustomRole для настраиваемых ролей. Задайте значение false или BuiltInRole для встроенных ролей. |
Description description |
Да | Строка | Описание пользовательской роли. Может содержать буквы, цифры, пробелы и специальные знаки. Максимальное число символов — 2048. |
Actions actions |
Да | String[] | Массив строк, указывающий действия уровня управления, которые позволяет выполнять роль. Дополнительные сведения см. в разделе Actions. |
NotActions notActions |
No | String[] | Массив строк, указывающий действия уровня управления, исключенные из разрешенного Actions . Дополнительные сведения см. в разделе NotActions. |
DataActions dataActions |
No | String[] | Массив строк, указывающих действия плоскости данных, которые роль позволяет выполнять данные в этом объекте. Если вы создаете пользовательскую роль с DataActions помощью, эта роль не может быть назначена в области группы управления. Дополнительные сведения см. в статье DataActions. |
NotDataActions notDataActions |
No | String[] | Массив строк, указывающий действия плоскости данных, исключенные из разрешенного DataActions . Дополнительные сведения см. в статье NotDataActions. |
AssignableScopes assignableScopes |
Да | String[] | Массив строк, который указывает области, в которых пользовательская роль может быть назначена. Максимальное число AssignableScopes — 2000. Дополнительные сведения см. в разделе AssignableScopes. |
Строки разрешений не учитывают регистр. При создании пользовательских ролей разрешения рекомендуется указывать так, как они приводятся в статье Операции с поставщиками ресурсов Azure.
Разрешения с подстановочными знаками
Actions
, NotActions
, DataActions
и NotDataActions
поддерживают подстановочные знаки (*
) для определения разрешений. Подстановочный знак (*
) расширяет действие разрешения на все, что соответствует введенной строке действий. Пусть, например, решено добавить все разрешения, связанные с Управлением затратами Azure и экспортом. Можно добавить все следующие строки действий.
Microsoft.CostManagement/exports/action
Microsoft.CostManagement/exports/read
Microsoft.CostManagement/exports/write
Microsoft.CostManagement/exports/delete
Microsoft.CostManagement/exports/run/action
Вместо добавления всех этих строк можно просто добавить строку с подстановочными знаками. Например, следующая строка с подстановочными знаками эквивалентна предыдущим пяти строкам. Сюда также входят все будущие разрешения экспорта, которые могут быть добавлены.
Microsoft.CostManagement/exports/*
Примечание.
Рекомендуется указывать Actions
и DataActions
явно не использовать подстановочный знак (*
). Дополнительный доступ и разрешения, предоставленные в будущем Actions
или DataActions
может быть нежелательным поведением с помощью подстановочного знака.
Кто может создавать, удалять, обновлять или просматривать пользовательскую роль
Как и в случае со встроенными ролями, свойство AssignableScopes
указывает области, в которых роль может быть назначена. Свойство AssignableScopes
пользовательской роли также определяет, кто может создавать, удалять, изменять или просматривать пользовательскую роль.
Задача | Действие | Description |
---|---|---|
Создание или удаление пользовательской роли | Microsoft.Authorization/ roleDefinitions/write |
Пользователи, которым предоставлено это действие для всех AssignableScopes настраиваемых ролей, могут создавать пользовательские роли (или удалять) для использования в этих областях. Например, Владельцы или Администраторы доступа пользователей групп управления, подписок и групп ресурсов. |
Обновление пользовательской роли | Microsoft.Authorization/ roleDefinitions/write |
Пользователи, которым предоставлено это действие для всех AssignableScopes настраиваемых ролей, могут обновлять пользовательские роли в этих областях. Например, Владельцы или Администраторы доступа пользователей групп управления, подписок и групп ресурсов. |
Просмотр пользовательской роли | Microsoft.Authorization/ roleDefinitions/read |
Пользователи, которым предоставлено это действие в области, могут просматривать пользовательские роли, доступные для назначения в этой области. Все встроенные роли позволяют использовать настраиваемые роли для назначения. |
Примечание.
Даже если роль переименована, идентификатор роли остается прежним. Если вы используете скрипты или автоматизацию для создания назначений ролей, рекомендуется использовать уникальный идентификатор роли вместо имени роли. Таким образом, если роль переименована, скорее всего, скрипты будут работать.
Поиск назначений ролей для удаления настраиваемой роли
Прежде чем удалить пользовательскую роль, необходимо удалить все назначения ролей, которые используют пользовательскую роль. При попытке удалить пользовательскую роль с назначениями ролей вы получите следующее сообщение: There are existing role assignments referencing role (code: RoleDefinitionHasAssignments)
Ниже приведены инструкции по поиску назначений ролей перед удалением настраиваемой роли:
- Перечисление определения настраиваемой роли.
- В разделе AssignableScopes получите группы управления, подписки и группы ресурсов.
- Переключите и перечислите
AssignableScopes
назначения ролей. - Удалите назначения ролей, которые используют пользовательскую роль.
- Если вы используете microsoft Entra управление привилегированными пользователями, удалите соответствующие настраиваемые назначения ролей.
- Удалите пользовательскую роль.
Дополнительные сведения о том, как найти неиспользуемые пользовательские роли, см. в разделе "Симптом". Дополнительные определения ролей не могут быть созданы.
Ограничения настраиваемых ролей
В следующем списке описаны ограничения для настраиваемых ролей.
- Каждый клиент может иметь до 5000 пользовательских ролей.
- Microsoft Azure, управляемый 21Vianet, может иметь до 2000 пользовательских ролей для каждого клиента.
- Нельзя задать
AssignableScopes
в качестве корневой области ("/"
). - В
AssignableScopes
нельзя использовать подстановочные знаки (*
). Это ограничение на применение подстановочных знаков позволяет гарантировать, что пользователь не сможет получить доступ к области, изменив определение роли. - В строке действия можно использовать только один подстановочный знак.
- В
AssignableScopes
настраиваемой роли можно определить только одну группу управления. - Azure Resource Manager не проверяет существование группы управления в определении
AssignableScopes
роли. - Настраиваемые роли с
DataActions
нельзя назначить в области группы управления. - Вы можете создать настраиваемую роль с
DataActions
одной группой управления и вAssignableScopes
ней. Вы не можете назначить пользовательскую роль в самой области группы управления; однако можно назначить пользовательскую роль в области подписок в группе управления. Это может быть полезно, если необходимо создать одну настраиваемую роль сDataActions
помощью нескольких подписок, а не создавать отдельную пользовательскую роль для каждой подписки.
Дополнительные сведения о пользовательских ролях и группах управления см. в статье Что такое группы управления Azure?
Форматы входных и выходных данных
Для создания настраиваемой роли с помощью командной строки, как правило, используется JSON, чтобы указать нужные свойства настраиваемой роли. В зависимости от используемых средств форматы входных и выходных данных будут немного отличаться. В этом разделе перечислены форматы входных и выходных данных в зависимости от инструмента.
Azure PowerShell
Чтобы создать настраиваемую роль с помощью Azure PowerShell, необходимо указать следующие входные данные.
{
"Name": "",
"Description": "",
"Actions": [],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": []
}
Чтобы изменить настраиваемую роль с помощью Azure PowerShell, необходимо указать следующие входные данные. Обратите внимание, что было добавлено свойство Id
.
{
"Name": "",
"Id": "",
"Description": "",
"Actions": [],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": []
}
Ниже приведен пример выходных данных при перечислении настраиваемой роли с помощью Azure PowerShell и команды ConvertTo-JSON.
{
"Name": "",
"Id": "",
"IsCustom": true,
"Description": "",
"Actions": [],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": []
}
Azure CLI
Чтобы создать или изменить настраиваемую роль с помощью Azure CLI, необходимо указать следующие входные данные. Этот формат совпадает с форматом, используемым при создании настраиваемой роли с помощью Azure PowerShell.
{
"Name": "",
"Description": "",
"Actions": [],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": []
}
Ниже приведен пример выходных данных при перечислении настраиваемой роли с помощью Azure CLI.
[
{
"assignableScopes": [],
"description": "",
"id": "",
"name": "",
"permissions": [
{
"actions": [],
"dataActions": [],
"notActions": [],
"notDataActions": []
}
],
"roleName": "",
"roleType": "CustomRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
]
REST API
Чтобы создать или изменить настраиваемую роль с помощью REST API, необходимо указать следующие входные данные. Этот формат совпадает с форматом, который создается при создании настраиваемой роли с помощью портала Azure.
{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": [],
"permissions": [
{
"actions": [],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
]
}
}
Ниже приведен пример выходных данных при перечислении настраиваемой роли с помощью REST API.
{
"properties": {
"roleName": "",
"type": "CustomRole",
"description": "",
"assignableScopes": [],
"permissions": [
{
"actions": [],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"createdOn": "",
"updatedOn": "",
"createdBy": "",
"updatedBy": ""
},
"id": "",
"type": "Microsoft.Authorization/roleDefinitions",
"name": ""
}