Поделиться через


Управление доступом на основе ролей Azure в средах развертывания Azure

В этой статье описываются различные встроенные роли, поддерживаемые средами развертывания Azure, и способы их сопоставления с ролями организации, такими как инженер платформы и руководитель разработки.

Управление доступом на основе ролей Azure (RBAC) задает встроенные определения ролей, которые описывают применяемые разрешения. Вы назначаете пользователю или группе это определение роли с помощью назначения ролей для определенной области. Областью может быть отдельный ресурс, группа ресурсов или подписка. В следующем разделе вы узнаете, какие встроенные роли поддерживают среды развертывания Azure.

Общие сведения см. в статье Что такое управление доступом на основе ролей в Azure (Azure RBAC)?

Примечание.

При внесении изменений в назначение ролей может потребоваться несколько минут для распространения этих обновлений.

Встроенные роли

В этой статье встроенные роли Azure логически группируются в три типа ролей организации на основе их влияния:

  • Роли инженера платформы: влияние разрешений для центров разработки, каталогов и проектов
  • Dev Manager: влияние разрешений на ресурсы на основе проекта
  • Роли разработчика: влияние разрешений для пользователей

Ниже приведены встроенные роли, поддерживаемые средами развертывания Azure.

Тип роли организации Встроенная роль Description
Инженер платформы Ответственный Предоставьте полный контроль для создания центров разработки, каталогов и проектов и предоставления разрешений другим пользователям. Дополнительные сведения о роли владельца.
Инженер платформы Участник Предоставьте полный контроль для создания и управления центрами разработки, каталогами и проектами, за исключением назначения ролей другим пользователям. Дополнительные сведения о роли участника.
Диспетчер разработки Администратор проекта DevCenter Предоставьте разрешение на управление определенными аспектами проектов и сред. Дополнительные сведения о роли администратора проекта DevCenter.
разработчик. Средство чтения сред развертывания Предоставьте разрешение на просмотр всех сред в проекте. Дополнительные сведения о роли читателя сред развертывания.
разработчик. Пользователь сред развертывания Предоставьте разрешение на создание сред и полный контроль над создаваемыми средами. Дополнительные сведения о роли пользователя сред развертывания.

Область назначения ролей

В Azure RBAC область — это набор ресурсов, к которым применяется доступ. При назначении роли важно понимать область, чтобы предоставить только необходимый доступ.

В Azure область действия можно задать на четырех уровнях: группы управления, подписки, группы ресурсов и ресурса. Структура областей строится на отношениях "родитель-потомок". Каждый уровень иерархии делает область более конкретной. Вы можете назначать роли на любом из этих уровней области действия. Выбранный уровень определяет, насколько широка область применения роли. На более низких уровнях наследуются разрешения ролей более высоких уровней. Дополнительные сведения о области для Azure RBAC.

Для сред развертывания Azure рассмотрим следующие области:

Область применения Description
Подписка Используется для управления выставлением счетов и безопасностью для всех ресурсов и служб Azure. Как правило, только инженеры платформы имеют доступ на уровне подписки, так как это назначение роли предоставляет доступ ко всем ресурсам в подписке.
Группа ресурсов Логический контейнер для группировки ресурсов. Назначение ролей для группы ресурсов предоставляет разрешение группе ресурсов и всем ресурсам в ней, таким как центры разработки, проекты и среды развертывания.
Центр разработки (ресурс) Коллекция проектов, требующих аналогичных параметров. Назначение ролей для центра разработки предоставляет разрешение самому центру разработки. Проекты и среды развертывания не наследуют разрешения, назначенные центрам разработки.
Project (ресурс) Ресурс Azure, используемый для применения общих параметров конфигурации при создании сред развертывания. Назначение ролей для проекта предоставляет разрешение только для этого конкретного проекта.
Тип среды (ресурс) Ресурс Azure, используемый для определения типов сред, которые можно создать, например песочницу, разработку, тестирование или рабочую среду. Типы среды определяются на уровне центра разработки и настраиваются на уровне проекта. Назначение ролей для типа среды развертывания предоставляет разрешение на этот тип среды в проекте, а не другим типам сред в том же проекте.

Схема с областями назначения ролей для сред развертывания Azure

Роли для распространенных действий в средах развертывания

В следующей таблице показаны распространенные действия в средах развертывания и роль, необходимая для выполнения этого действия пользователем.

Деятельность Тип роли Роль Область применения
Предоставьте разрешение на создание группы ресурсов. Инженер платформы Владелец или Участник Отток подписок
Предоставьте разрешение на отправку запроса в службу поддержки Майкрософт, включая запрос на увеличение квоты. Инженер платформы Владелец, участник, участник запроса на поддержку Отток подписок
Предоставьте разрешение на создание типов среды в проекте. Инженер платформы Настраиваемая роль: Microsoft.Authorization/roleAssignments/write

Owner, Участник или Администратор проекта
Проект подписки


Предоставьте разрешение на назначение ролей другим пользователям. Инженер платформы Ответственный Группа ресурсов
Предоставление разрешения:
создание и управление центрами разработки и проектами.
— Присоединение или отсоединение каталога к центру разработки или проекту.
Инженер платформы Владелец, участник Группа ресурсов
Предоставьте разрешение на включение и отключение каталогов проектов. Диспетчер разработки Владелец, участник Центр разработки
Предоставьте разрешение на создание всех сред в проекте и управление ими.
— Добавление, синхронизация, удаление каталога (каталоги уровня проекта должны быть включены в центре разработки).
— настройте дату и время окончания срока действия, чтобы активировать автоматическое удаление.
— обновление и удаление типов сред.
— Удаление сред.
Диспетчер разработки Администратор проекта DevCenter Project
Просмотр всех сред в проекте. Диспетчер разработки Средство чтения сред развертывания Project
Создайте собственные среды и управляйте ими в проекте. User Пользователь сред развертывания Project
Создание каталогов и управление ими в репозитории GitHub или Azure Repos. Диспетчер разработки Не регулируется RBAC.
Пользователю необходимо назначить разрешения через Azure DevOps или GitHub.
Репозиторий

Внимание

Подписка организации используется для управления выставлением счетов и безопасностью для всех ресурсов и служб Azure. Вы можете назначить роль владельца или участника в подписке. Как правило, только инженеры платформы имеют доступ на уровне подписки, так как это включает полный доступ ко всем ресурсам в подписке.

Роли инженера платформы

Чтобы предоставить пользователям разрешение на управление средами развертывания Azure в подписке вашей организации, необходимо назначить им роль владельца или участника .

Назначьте эти роли группе ресурсов. Центр разработки и проекты в группе ресурсов наследуют эти назначения ролей. Типы среды наследуют назначения ролей через проекты.

Роль владельца

Назначьте роль владельца, чтобы предоставить пользователю полный доступ к созданию и управлению центрами разработки и проектами, а также предоставлять разрешения другим пользователям. Если у пользователя есть роль владельца в группе ресурсов, они могут выполнять следующие действия во всех ресурсах в группе ресурсов:

  • Назначьте роли инженерам платформы, чтобы они могли управлять ресурсами сред развертывания.
  • Создание центров разработки, проектов и типов среды.
  • Присоединение и отключение каталогов.
  • Просмотр, удаление и изменение параметров для всех центров разработки, проектов и типов среды.

Внимание

При назначении роли "Владелец" или "Участник" в группе ресурсов эти разрешения также применяются к ресурсам, связанным с ней, которые существуют в группе ресурсов. Например, ресурсы, такие как виртуальные сети, учетные записи хранения, коллекции вычислений и многое другое.

Роль участника

Назначьте роль участника, чтобы предоставить пользователю полный контроль над созданием или управлением центрами разработки и проектами в группе ресурсов. Роль участника имеет те же разрешения, что и роль владельца, за исключением следующих:

  • Выполнение назначений ролей

Настраиваемая роль

Чтобы создать тип среды уровня проекта в средах развертывания, необходимо назначить роль владельца или роль администратора доступа пользователей для подписки, сопоставленной в типе среды в проекте. Кроме того, чтобы избежать назначения широких разрешений на уровне подписки, можно создать и назначить пользовательскую роль, которая применяет разрешения на запись. Примените настраиваемую роль в подписке, сопоставленной в типе среды в проекте.

Чтобы узнать, как создать пользовательскую роль с помощью Microsoft.Authorization/roleAssignments/write и назначить ее на уровне подписки, см. статью "Создание настраиваемой роли".

Помимо настраиваемой роли, пользователю необходимо назначить роль владельца, участника или администратора проекта в проекте, в котором создается тип среды.

Роли диспетчера разработки

Существует одна роль диспетчера разработки: администратор проекта DevCenter. Эта роль имеет более ограниченные разрешения на более низких уровнях, чем роли инженера платформы. Эту роль можно назначить диспетчерам разработки, чтобы позволить им выполнять административные задачи для своей команды.

Роль администратора проекта DevCenter

Назначьте роль администратора проекта DevCenter, чтобы разрешить пользователю:

  • Управление всеми средами в проекте.
  • Добавление, синхронизация, удаление каталога (каталоги уровня проекта должны быть включены в центре разработки)
  • Обновление и удаление типов среды.
  • Настройте дату и время окончания срока действия, чтобы активировать автоматическое удаление.
  • Удаляет среды.

Роли разработчика

Эти роли предоставляют разработчикам разрешения, необходимые для просмотра, создания и управления средами.

Пользователь сред развертывания

Назначьте роль "Пользователь сред развертывания", чтобы предоставить пользователям разрешение на создание сред и полный контроль над создаваемыми средами.

  • Создание
  • DELETE
  • Задайте дату и время окончания срока действия.
  • Повторное развертывание среды.

Средство чтения сред развертывания

Назначьте роль читателя сред развертывания, чтобы предоставить пользователю разрешение на просмотр всех сред в проекте.

Тип среды проекта определяет два набора ролей для ресурсов среды, роль, назначенную создателю, и роль, назначенную дополнительным пользователям и группам.

Когда разработчик создает среду на основе типа среды, им назначается роль, указанная создателю для ресурсов среды. Другие разработчики назначают любые роли для групп, к которым они относятся, если таковые имеются. У них есть разрешение на ресурсы среды, но не для самой среды. В этом случае назначение роли читателя сред развертывания позволяет разработчикам просматривать среду.

Система управления идентификацией и доступом (IAM)

Страница управления доступом (IAM) в портал Azure используется для настройки управления доступом на основе ролей Azure в ресурсах сред развертывания Azure. Встроенные роли можно использовать для отдельных лиц и групп в Active Directory. На следующем снимке экрана показана интеграция с Active Directory (Azure RBAC) с использованием функции управления доступом (IAM) на портале Azure:

Подробные инструкции см. в статье Назначение ролей Azure с помощью портала Microsoft Azure.

Центр разработки, группа ресурсов и структура проекта

Ваша организация должна инвестировать время заранее, чтобы спланировать размещение центров разработки, а также структуру групп ресурсов и проектов.

Центры разработки: упорядочить центры разработки по набору проектов, которым вы хотите управлять, применять аналогичные параметры и предоставлять аналогичные шаблоны.

Организации могут использовать один или несколько центров разработки. Как правило, каждая подорганизация в организации имеет собственный центр разработки. Вы можете создать несколько центров разработки в следующих случаях:

  • Конкретные конфигурации доступны для подмножества проектов.
  • Разные команды принадлежат и поддерживают ресурс центра разработки в Azure.

Проекты: связанные с каждой командой разработчиков или группой людей, работающих над одним приложением или продуктом.

Типы среды: отражают этап разработки или типа среды — разработку, тестирование, промежуточное, предварительное, проd, промежуточное, промежуточное и т. д. Вы можете выбрать соглашение об именовании, подходящее для вашей среды.

Планирование особенно важно при назначении ролей группе ресурсов, так как она также применяет разрешения ко всем ресурсам в группе ресурсов, включая проекты и типы среды.

Чтобы убедиться, что пользователям предоставлено разрешение только для соответствующих ресурсов:

  • Создайте группы ресурсов, содержащие только ресурсы среды развертывания.
  • Упорядочение проектов в соответствии с необходимыми типами среды и разработчиками, которым должен быть доступ.

Например, можно создать отдельные проекты для разных команд разработчиков, чтобы изолировать ресурсы каждой команды. Затем руководители разработчиков в проекте могут быть назначены роли администратора проекта, которая предоставляет им доступ только к ресурсам своей команды.

Внимание

Запланируйте структуру заранее, так как невозможно переместить ресурсы сред развертывания, такие как проекты или среды, в другую группу ресурсов после их создания.

Структура каталога

Среды развертывания Azure используют определения среды для развертывания ресурсов Azure для разработчиков. Определение среды состоит из шаблона IaC и файла среды, который выступает в качестве манифеста. Шаблон определяет среду, а файл среды предоставляет метаданные о шаблоне.

Среды развертывания Azure хранят определения среды в репозитории GitHub или репозитории Azure DevOps Services, известном как каталог. Вы можете присоединить каталог к центру разработки или к проекту. Команды разработчиков используют элементы, предоставляемые в каталоге, для создания сред в Azure.

Вы можете присоединить каталоги к центру разработки или проекту для управления определениями среды на разных уровнях. При принятии решения о присоединении каталогов следует учитывать потребности каждой команды разработчиков.