Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эта статья предназначена для инженеров платформ, центральных ИТ-администраторов и других администраторов более высокого уровня, которые планируют развертывания Microsoft Dev Box и управляют ими. В нем описываются различные встроенные роли, поддерживаемые Microsoft Dev Box, и способы их сопоставления с ролями организации, такими как инженер платформы и руководитель разработки, чтобы вы могли спланировать правильную модель разрешений перед развертыванием Dev Box.
Управление доступом на основе ролей Azure (RBAC) указывает встроенные роли, определяющие применяемые разрешения. Вместо предоставления детализированных разрешений отдельным пользователям или группам вы назначаете роли, которые объединяют связанные разрешения, чтобы обеспечить согласованное применение и аудит доступа между ресурсами. Вы назначаете пользователю или группе это определение роли с помощью назначения ролей для определенной области. Областью может быть отдельный ресурс, группа ресурсов или подписка. В следующем разделе вы узнаете, какие встроенные роли Microsoft Dev Box поддерживают.
Общие сведения см. в статье Что такое управление доступом на основе ролей в Azure (Azure RBAC)?
Примечание.
При внесении изменений в назначение ролей может потребоваться несколько минут для распространения этих обновлений.
Встроенные роли
В этой статье встроенные роли Azure логически группируются в три типа ролей организации на основе их влияния:
Роли инженера платформы: влияние разрешений для центров разработки, каталогов и проектов
Диспетчер разработки: влияние разрешений на ресурсы на основе проекта
Роли разработчика: влияние разрешений для пользователей
Ниже приведены встроенные роли, поддерживаемые Microsoft Dev Box:
| Тип роли организации | Встроенная роль | Description |
|---|---|---|
| Инженер платформы | Ответственный | Предоставьте полный контроль для создания центров разработки, каталогов и проектов и предоставления разрешений другим пользователям. Дополнительные сведения о роли владельца. |
| Инженер платформы | Участник | Предоставьте полный контроль для создания и управления центрами разработки, каталогами и проектами, за исключением назначения ролей другим пользователям. Дополнительные сведения о роли участника. |
| Инженер платформы | Владелец DevCenter | Предоставить доступ к управлению всеми ресурсами Microsoft.DevCenter и управлять ими. Дополнительные сведения о роли владельца DevCenter. |
| Диспетчер разработки | Администратор проекта DevCenter | Предоставьте разрешение на управление определенными аспектами проектов и полей разработки. Дополнительные сведения о роли администратора проекта DevCenter. |
| разработчик. | Пользователь Dev Box | Предоставьте разрешение на создание полей разработки и полный контроль над создаваемыми полями разработки. Дополнительные сведения о роли пользователя Dev Box. |
Область назначения ролей
В Azure RBAC область — это набор ресурсов, к которым применяется доступ. При назначении роли важно понимать область, чтобы предоставить только необходимый доступ.
В Azure область действия можно задать на четырех уровнях: группы управления, подписки, группы ресурсов и ресурса. Структура областей строится на отношениях "родитель-потомок". Каждый уровень иерархии делает область более конкретной. Вы можете назначать роли на любом из этих уровней области действия. Выбранный уровень определяет, насколько широка область применения роли. На более низких уровнях наследуются разрешения ролей более высоких уровней. Дополнительные сведения о области для Azure RBAC.
Для Microsoft Dev Box рассмотрим следующие области:
| Scope | Description |
|---|---|
| Подписка | Используется для управления выставлением счетов и безопасностью для всех ресурсов и служб Azure. Как правило, только инженеры платформы имеют доступ на уровне подписки, так как это назначение роли предоставляет доступ ко всем ресурсам в подписке. |
| Группа ресурсов | Логический контейнер для группировки ресурсов. Назначение ролей для группы ресурсов предоставляет разрешение группе ресурсов и всем ресурсам в нем, таким как центры разработки, определения полей разработки, пулы средств разработки, проекты и поля разработки. |
| Центр разработки (ресурс) | Коллекция проектов, требующих аналогичных параметров. Назначение ролей для центра разработки предоставляет разрешение самому центру разработки. Разрешения, назначенные центрам разработки, не наследуются другими ресурсами поля разработки. |
| Project (ресурс) | Ресурс Azure, используемый для применения общих параметров конфигурации при создании поля разработки. Назначение ролей для проекта предоставляет разрешение только для этого конкретного проекта. |
| Пул полей разработки (ресурс) | Коллекция полей разработки, которыми вы управляете вместе, и к которым применяются аналогичные параметры. Назначение ролей для пула средств разработки предоставляет разрешение только для этого конкретного пула средств разработки. |
| Определение поля разработки (ресурс) | Ресурс Azure, указывающий исходный образ и размер, включая размер вычислительных ресурсов и размер хранилища. Назначение ролей для определения поля разработки предоставляет разрешение только для определенного определения поля разработки. |
Роли для распространенных действий Dev Box
В следующей таблице показаны распространенные действия Dev Box и роль, необходимая для выполнения этого действия пользователем.
| Действие (Activity) | Тип роли | Роль | Scope |
|---|---|---|---|
| Предоставьте разрешение на создание группы ресурсов. | Инженер платформы | Владелец или Участник | Подписка |
| Предоставьте разрешение на отправку запроса в службу поддержки Майкрософт, включая запрос емкости. | Инженер платформы | Владелец, участник, участник запроса на поддержку | Подписка |
| Предоставьте разрешение на создание виртуальных сетей и подсетей. | Инженер платформы | Участник сети | Группа ресурсов |
| Предоставьте разрешение на создание сетевого подключения. | Инженер платформы | Владелец или Участник | Группа ресурсов |
| Предоставьте разрешение на назначение ролей другим пользователям. | Инженер платформы | Ответственный | Группа ресурсов |
| Предоставление разрешения: создание и управление центрами разработки. — Добавление и удаление сетевых подключений. — Добавление и удаление коллекций вычислительных ресурсов Azure. — Создание определений поля разработки и управление ими. — создание и управление проектами. — Присоединение или управление каталогом к центру разработки или проекту (каталоги уровня проекта должны быть включены в центре разработки). — Настройка ограничений поля разработки. |
Инженер платформы | Участник | Группа ресурсов |
| Предоставьте разрешение на создание ресурсов Dev Box и управление ими без предоставления доступа к другим типам ресурсов в группе ресурсов.
— Центры разработки — проекты — определения поля разработки — пулы полей разработки |
Инженер платформы | Владелец DevCenter | Группа ресурсов |
| Предоставьте разрешение на добавление или удаление сетевого подключения для центра разработки. | Инженер платформы | Участник или владелец DevCenter | Центр разработки |
| Предоставьте разрешение на включение и отключение каталогов проектов. | Диспетчер разработки | Участник | Центр разработки |
| Предоставление разрешения: Добавление, синхронизация, удаление каталога (каталоги уровня проекта должны быть включены в центре разработки). — Создание пулов полей разработки. — Остановка, запуск, удаление полей разработки в пулах. |
Диспетчер разработки | Администратор проекта DevCenter | Project |
| Создайте собственные поля разработки и управляйте ими в проекте. | User | Пользователь Dev Box | Project |
| Создание каталогов и управление ими в репозитории GitHub или Azure Repos. | Диспетчер разработки | Не регулируется RBAC.
— Пользователю необходимо назначить разрешения через Azure DevOps или GitHub. |
Репозиторий |
Внимание
Подписка организации используется для управления выставлением счетов и безопасностью для всех ресурсов и служб Azure. Вы можете назначить роль владельца или участника в подписке. Как правило, только инженеры платформы имеют доступ на уровне подписки, так как это включает полный доступ ко всем ресурсам в подписке.
Роли инженеров платформы
Чтобы предоставить пользователям разрешение на управление Microsoft Dev Box в подписке вашей организации, вы можете назначить им роль владельца или участника в области группы ресурсов или роль владельца DevCenter в области центра разработки.
При использовании ролей владельца или участника назначьте их группе ресурсов. Центры разработки, сетевые подключения, определения поля разработки, пулы средств разработки и проекты в группе ресурсов наследуют эти назначения ролей.
Роль владельца
Назначьте роль владельца, чтобы предоставить пользователю полный контроль над созданием или управлением ресурсами Dev Box и предоставлением разрешений другим пользователям. Если у пользователя есть роль владельца в группе ресурсов, они могут выполнять следующие действия во всех ресурсах в группе ресурсов:
- Назначьте роли инженерам платформы, чтобы они могли управлять ресурсами Dev Box.
- Создание центров разработки, сетевых подключений, определений поля разработки, пулов полей разработки и проектов.
- Просмотр, удаление и изменение параметров для всех центров разработки, сетевых подключений, определений поля разработки, пулов средств разработки и проектов.
- Присоединение и отключение каталогов.
Роль участника
Назначьте роль участника, чтобы предоставить пользователю полный контроль над созданием или управлением центрами разработки и проектами в группе ресурсов. Роль участника имеет те же разрешения, что и роль владельца, за исключением следующих:
- Выполнение назначений ролей.
Внимание
При назначении роли владельца или участника в группе ресурсов эти разрешения также применяются к связанным ресурсам, не связанным с Dev Box, которые существуют в группе ресурсов.
Роль владельца DevCenter
Роль владельца DevCenter можно назначить в области группы ресурсов или в области центра разработки.
Роль владельца DevCenter на уровне группы ресурсов
Назначьте роль владельца DevCenter группе ресурсов, чтобы предоставить пользователю полный контроль над ресурсами Microsoft.DevCenter, не предоставляя более широкий доступ к другим ресурсам в группе ресурсов.
Если у пользователя есть роль владельца DevCenter в группе ресурсов, они могут:
- Создание, обновление и удаление центров разработки в этой группе ресурсов.
- Создание, обновление и удаление проектов в этой группе ресурсов.
- Создание, обновление и удаление пулов полей разработки и определений полей разработки в этой группе ресурсов.
- Управляйте каталогами, сетевыми подключениями и галереями вычислительных ресурсов, связанными с центрами разработки в группе ресурсов.
- Делегируйте администрирование проекта, назначив роли администратор проекта DevCenter и пользователь DevCenter Dev Box на уровне проекта.
Роль владельца DevCenter в пределах центра разработки
Назначьте роль владельца DevCenter центру разработки, чтобы предоставить пользователю полный контроль над ресурсами Microsoft.DevCenter, не предоставляя более широкий доступ к другим центрам разработки и их ресурсам. Пользователи с этой ролью, назначенные центру разработки, не могут создавать новые центры разработки.
Если у пользователя есть роль владельца DevCenter в центре разработки, они могут:
- Создание, обновление и удаление проектов в этом центре разработки.
- Создание, обновление и удаление пулов полей разработки и определений полей разработки в этом центре разработки.
- Управление каталогами, сетевыми подключениями и коллекциями вычислений, подключенными к центру разработки.
- Делегируйте администрирование проекта, назначив роли администратор проекта DevCenter и пользователь DevCenter Dev Box на уровне проекта.
Роли для диспетчеров разработки
Существует одна роль диспетчера разработки: администратор проекта DevCenter. Эта роль имеет более ограниченные разрешения на более низких уровнях, чем роли инженера платформы. Эту роль можно назначить диспетчерам разработки, чтобы позволить им выполнять административные задачи для своей команды.
Роль администратора проекта DevCenter
Назначьте администратору проекта DevCenter, чтобы включить:
Добавление, синхронизация, удаление каталога (каталоги уровня проекта должны быть включены в центре разработки).
Создание пулов полей разработки.
Остановка, запуск, удаление полей разработки в пулах.
Роли для разработчиков
Существует одна роль разработчика: пользователь Dev Box. Эта роль позволяет разработчикам создавать собственные поля разработки и управлять ими.
Роль пользователя Dev Box
Назначьте роль пользователя Dev Box, чтобы предоставить пользователям разрешение на создание полей разработки и полный контроль над создаваемыми полями разработки. Разработчики могут выполнять следующие действия в любом создаваемом поле разработки:
- Создание
- Запуск и остановка
- Перезагрузить
- Задержка запланированного завершения работы
- Удаление
Система управления идентификацией и доступом (IAM)
Страница управления доступом (IAM) в портал Azure используется для настройки управления доступом на основе ролей Azure на ресурсах Microsoft Dev Box. Встроенные роли можно использовать для отдельных лиц и групп в Active Directory. На следующем снимке экрана показана интеграция с Active Directory (Azure RBAC) с использованием функции управления доступом (IAM) на портале Azure:
Подробные инструкции см. в статье Назначение ролей Azure с помощью портала Microsoft Azure.
Центр разработки, группа ресурсов и структура проекта
Ваша организация должна инвестировать время заранее, чтобы спланировать размещение центров разработки, а также структуру групп ресурсов и проектов.
Центры разработки: упорядочение центров разработки по набору проектов, которым вы хотите управлять вместе, применять аналогичные параметры и предоставлять аналогичные шаблоны.
Организации могут использовать один или несколько центров разработки. Как правило, каждая вложенная организация в организации имеет собственный центр разработки. Вы можете создать несколько центров разработки в следующих случаях:
Если требуется, чтобы определенные конфигурации были доступны для подмножества проектов.
Если разные команды должны принадлежать и поддерживать ресурс центра разработки в Azure.
Проекты. Связанные с каждой командой разработчиков или группой людей, работающих над одним приложением или продуктом.
Планирование особенно важно при назначении ролей группе ресурсов, так как она также применяет разрешения ко всем ресурсам в группе ресурсов, включая центры разработки, сетевые подключения, определения поля разработки, пулы средств разработки и проекты.
Чтобы убедиться, что пользователям предоставлено разрешение только для соответствующих ресурсов:
Создайте группы ресурсов, содержащие только ресурсы Dev Box.
Упорядочение проектов в соответствии с определением и пулами полей разработки, необходимыми для разработчиков, и разработчикам, которым должен быть доступ. Важно отметить, что пулы полей разработки определяют расположение создания поля разработки. Разработчики должны создавать поля разработки в расположении, близком к ним, для наименьшей задержки.
Например, можно создать отдельные проекты для разных команд разработчиков, чтобы изолировать ресурсы каждой команды. Затем руководители разработчиков в проекте могут быть назначены роли администратора проекта, которая предоставляет им доступ только к ресурсам своей команды.
Внимание
Запланируйте структуру заранее, так как невозможно переместить ресурсы Dev Box, такие как проекты, в другую группу ресурсов после их создания.
Структура каталога
Microsoft Dev Box использует каталоги, чтобы разработчики могли развертывать настройки для полей разработки с помощью каталога задач и файла настройки для установки программного обеспечения, добавления расширений, клонированных репозиториев и т. д.
Microsoft Dev Box хранит каталоги в репозитории GitHub или репозитории Azure DevOps Services. Вы можете присоединить каталог к центру разработки или к проекту.
Вы можете подключить один или несколько каталогов к центру разработки и управлять всеми настройками на этом уровне. Чтобы обеспечить более подробную степень в том, как разработчики получают доступ к настройкам, можно присоединить каталоги на уровне проекта. При планировании присоединения каталогов следует учитывать потребности каждой группы разработчиков.