Управление доступом в Managed Service for GitLab
В этом разделе вы узнаете:
- на какие ресурсы можно назначить роль;
- какие роли действуют в сервисе;
- какие роли необходимы для того или иного действия.
Для использования сервиса необходимо авторизоваться в консоли управления с аккаунтом на Яндексе или с федеративным аккаунтом.
Об управлении доступом
Все операции в Yandex Cloud проверяются в сервисе Yandex Identity and Access Management. Если у субъекта нет необходимых разрешений, сервис вернет ошибку.
Чтобы выдать разрешения к ресурсу, назначьте роли на этот ресурс субъекту, который будет выполнять операции. Роли можно назначить аккаунту на Яндексе, сервисному аккаунту, федеративным пользователям, группе пользователей или системной группе. Подробнее читайте в разделе Как устроено управление доступом в Yandex Cloud.
Назначать роли на ресурс могут те, у кого есть роль admin
или resource-manager.clouds.owner
на этот ресурс.
На какие ресурсы можно назначить роль
Роль можно назначить на облако или каталог. Роли на облако действуют и на вложенные каталоги.
Какие роли действуют в сервисе
gitlab.viewer
Роль gitlab.viewer
позволяет просматривать список инстансов Managed Service for GitLab, информацию о каждом инстансе и его резервных копиях.
gitlab.editor
Роль gitlab.editor
позволяет создавать, редактировать и удалять инстансы, создавать и восстанавливать резервные копии, а также переносить и запускать запланированное обслуживание.
gitlab.admin
Роль gitlab.admin
позволяет создавать, редактировать и удалять инстансы, а также выдавать права другим пользователям.
Эта роль назначается по умолчанию. Включает в себя роль gitlab.editor
.
viewer
Роль viewer
дает разрешения на чтение к ресурсам.
Роль viewer
включает все разрешения, которые дает роль auditor
. В отличие от роли auditor
, роль viewer
предоставляет возможность доступа к данным сервиса в режиме чтения.
Например, роль viewer
позволяет выполнять следующие операции:
- Просмотр информации о ресурсе.
- Получение списка вложенных ресурсов, например списка виртуальных машин в каталоге.
- Просмотр списка операций с ресурсом.
editor
Роль editor
дает разрешения на все операции для управления ресурсом, кроме назначения ролей другим пользователям. Роль editor
включает все разрешения, которые дает роль viewer
.
Например, роль editor
позволяет выполнять следующие операции:
- Создание ресурса.
- Обновление ресурса.
- Удаление ресурса.
admin
Роль admin
дает все разрешения для управления ресурсом, включая назначение ролей другим пользователям. Можно назначать любые роли за исключением resource-manager.clouds.owner
.
Роль admin
включает все разрешения, которые дает роль editor
.
Например, роль admin
позволяет выполнять следующие операции:
- Установить права доступа к ресурсу.
- Изменить права доступа к ресурсу.
resource-manager.clouds.member
Сама по себе роль не дает права выполнять какие-либо операции и используется только в сочетании с другими ролями.
Роль полезна, если пользователю необходим доступ к ресурсам Yandex Cloud не только через CLI, API и Terraform, но и через консоль управления.
resource-manager.clouds.member
— это одна из ролей, которая даст пользователю доступ к консоли управления. Так же для этой цели подойдет любая роль из списка:
-
На организации или облаке:
resource-manager.admin
;resource-manager.editor
;resource-manager.viewer
;admin
;editor
;viewer
.
-
На облаке:
resource-manager.clouds.owner
.
Каждая роль из списка даст пользователю не только доступ к консоли, но и свои разрешения на ресурсы облака или организацию. В зависимости от роли это может быть чтение информации обо всех ресурсах в облаке или создание и удаление любого ресурса.
Чтобы не давать пользователю дополнительных прав, используйте resource-manager.clouds.member
. Роль обеспечит доступ к консоли управления при минимальных дополнительных правах. Пользователь увидит только общую информацию об облаке, на которое ему назначена роль, но не сможет просмотреть ресурсы и права доступа к облаку.
Пример:
Администратор должен управлять сетевой связностью ресурсов во всех облаках организации. За несетевые ресурсы отвечают другие члены команды. Для этого случая можно использовать такую матрицу доступа:
Роль На ресурс Разрешает vpc.admin
Организация Управлять сетями, маршрутами, IP-адресами и другими ресурсами Virtual Private Cloud через CLI, API и Terraform во всех облаках организации resource-manager.clouds.member
Все облака организации Работать с Virtual Private Cloud в консоли управления, видеть общую информацию об облаках
Примечание
Если в организации много облаков и они часто создаются и удаляются, каждый раз назначать resource-manager.clouds.member
на облако будет неудобно. В этом случае можно заменить resource-manager.clouds.member
ролью resource-manager.viewer
— назначьте ее один раз на организацию, и администратор сможет работать в консоли управления с ресурсами Virtual Private Cloud всех облаков, включая будущие облака. Роль позволит видеть информацию обо всех облаках и каталогах, включая списки прав доступа.
resource-manager.clouds.owner
Роль resource-manager.clouds.owner
назначается на облако и делает пользователя владельцем облака. Владелец может выполнять любые операции с облаком и ресурсами в нем.
Только владелец облака может назначать и удалять у пользователей роль resource-manager.clouds.owner
.
У облака должен быть хотя бы один владелец. Пользователь, который создал облако, автоматически становится его владельцем. Единственный владелец облака не сможет отнять эту роль у себя.
Какие роли необходимы
Чтобы пользоваться сервисом, необходима роль gitlab.editor
или выше на каталог, в котором создаются проекты. Роль gitlab.viewer
позволит только просматривать список проектов и содержимое файлов, которые были загружены.
Вы всегда можете назначить роль, которая дает более широкие разрешения. Например, назначить gitlab.admin
вместо gitlab.editor
.