Ролевая модель управления доступом
Типы учетных записей пользователя VK Dev Platform приведены в таблице 1.
Тип | Описание |
|---|---|
Администратор VK Dev Platform | Первый пользователь VK Dev Platform, создается при развертывании VK Dev Platform. Имя учетной записи по умолчанию — Администрирует VK Dev Platform. Обладает доступом ко всем ресурсам VK Dev Platform во всех проектах разработки. Управляет:
|
Пользователи Портала управления разработкой | Создаются администратором VK Dev Platform. В рамках проекта разработки к ним применяется ролевая модель управления доступом |
Сервисный пользователь | Служебный пользователь, создается автоматически в каждом проекте разработки. Имя учетной записи генерируется автоматически в формате: Используется для взаимодействия внешних сервисов (инструментов автоматизации) с API VK Dev Platform |
Разграничение доступа пользователей к ресурсам VK Dev Platform обеспечивается ролевой моделью. В VK Dev Platform предусмотрены проектные роли. Назначаются в рамках проекта разработки через Портал управления разработкой. У каждой роли есть набор прав доступа, определяющий возможные действия над ресурсами VK Dev Platform.
Проектные роли в VK Dev Platform по умолчанию:
teamlead— руководитель группы.deplead— руководитель департамента.project_manager— руководитель проекта.developer— разработчик.devops— DevOps.qa— QA-инженер.devsec— специалист ИБ.techwriter— технический писатель.product_manager— менеджер продукта.analyst— аналитик.architect— архитектор.readonly— роль с правами на просмотр всех ресурсов VK Dev Platform и ресурсов интегрированных сервисов.service-account— сервисный пользователь.admin— администратор проекта разработки.
Права доступа в VK Dev Platform:
-
read— просмотр. -
create— создание интеграции или правила согласования. -
write— создание, редактирование. Относительно пользователей — добавление пользователя в проект разработки. -
delete— удаление ресурса VK Dev Platform. Относительно пользователей — удаление пользователя из проекта разработки. -
security_attributes— редактирование атрибутов доступа, приведенных в разделе Роли в проекте GitLab CE в зависимости от атрибутов доступа. -
deploy— развертывание инфраструктуры в окружении. -
undeploy— удаление инфраструктуры в окружении. -
gitlab:<РОЛЬ_В_GITLAB>— роль в проекте GitLab CE (подробнее — в разделе Роли в проекте GitLab CE в зависимости от атрибутов доступа). -
sonarqube:<РОЛЬ_В_SONARQUBE>— роль в проекте SonarQube (подробнее — в разделе Права доступа к проектам SonarQube). -
teamstorm:<РОЛЬ_В_TEAMSTORM>— роль в проекте TeamStorm (подробнее — в разделе Права доступа к пространствам в TeamStorm). -
nexus:<РОЛЬ_В_NEXUS>— роль в репозитории Sonatype Nexus Repository Manager OSS:-
nexus:repository-viewer— роль с привилегиямиbrowseиread. -
nexus:repository-editor— роль с привилегиямиbrowse,read,edit,addиdelete.Подробнее о привилегиях — в официальной документации Sonatype Nexus Repository.
-
-
create_from_template— создание репозитория из шаблона. -
create_empty— создание пустого репозитория. -
update— редактирование репозитория.
В таблице 2 и таблице 3 приведена матрица прав доступа к ресурсам VK Dev Platform по умолчанию.
Проектная роль | Ресурс VK Dev Platform | ||||
Проекты разработки | Пользователи | Репозитории | Окружения | Раннеры | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Проектная роль | Ресурс VK Dev Platform | ||||
Хранилища артефактов | Анализаторы кода | ALM-проекты | Внешние интеграции | Правила согласования | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Атрибуты доступа назначаются на репозиторий и предоставляют пользователям расширенные права доступа к проектам в GitLab CE в соответствии с ролями:
admin,service-account,teamlead— рольgitlab: ownerв GitLab CE.deplead,project_manager— рольgitlab: reporterв GitLab CE.developer— рольgitlab: developerв GitLab CE.readonly— рольgitlab: guestв GitLab CE.- Остальные роли — назначение роли в GitLab CE зависит от выбранного атрибута доступа (таблица 4).
Роль | Атрибут | ||||
shared | docs | devops | qa | devsec | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Без атрибутов доступа проектные роли имеют права на проекты в Gitlab CE, приведенные в разделе Матрица прав доступа.
Пользователям, наделенным проектными ролями VK Dev Platform, назначаются права доступа к проектам в SonarQube (таблица 5):
teamlead,devops— роль администратора в SonarQube.developer,qa,analyst— рольissueadminв SonarQube.- Остальные роли — роль
userв SonarQube.
Роль | Роль SonarQube | Права |
|---|---|---|
|
| Просмотр проекта ( Просмотр исходного кода ( Администрирование проблем ( Администрирование точек доступа безопасности ( Администрирование проекта ( Выполнение анализа проекта ( |
|
| Просмотр проекта ( Администрирование проблем ( |
|
| Просмотр проекта ( |
Пользователям, наделенным проектными ролями VK Dev Platform, назначаются права доступа к пространствам в TeamStorm (таблица 6):
teamlead,service-account— роль администратора в TeamStorm.readonly— роль гостя пространства в TeamStorm.- Остальные роли — роль пользователя в TeamStorm.
Роль | Роль SonarQube | Права |
|---|---|---|
|
| Редактирование имени и описания пространства. Управление доступами. Управление интеграциями. Удаление пространства. Управление типами. Управление атрибутами. Управление процессами |
|
| Работа с папками. Работа с представлениями. Работа с задачами. Работа с расширениями. Выгрузка данных |
|
| Просмотр проекта |