Настраиваемые роли Azure

Статья
11/16/2023

Если встроенные роли 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"
  }
]

Свойства пользовательской роли

В следующей таблице показано, что означают свойства настраиваемой роли.

Свойство	Обязательное поле	Тип	Описание
`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 назначения ролей.
Удалите назначения ролей, которые используют пользовательскую роль.
Удалите пользовательскую роль.

Ограничения настраиваемых ролей

В следующем списке описаны ограничения для настраиваемых ролей.

Каждый клиент может иметь до 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": ""
}