Ролевая модель KeyStack

Ролевая модель платформы KeyStack определяет доступ ко всем компонентам платформы. Контроль доступа к сервисам основан на модели RBAC (role-based access control). Пользователи получают доступ к различным программным интерфейсам в зависимости от их роли в проекте, домене или контексте системы. Эти роли могут назначаться любому субъекту (пользователю или группе) для любых сущностей (контекст системы, домен, проект).

Принципы организации ролевой модели

Ролевая модель построена по принципу наименьших привилегий. При применении ролевой модели:

  • любой доступ, включая доступ к обрабатываемым на платформе данным, осуществляется на основании перечисленных ролей;

  • доступ предоставляется только в рамках роли, получаемой из централизованного сервиса управления доступом к информационным ресурсам по результатам аутентификации пользователя, локальные роли не используются;

  • использование локальных технологических учётных записей для исполнения задач пользователей и администраторов запрещено;

  • исключена возможность доступа администратора к паролям и другим конфиденциальным данным пользователей системы.

Описание ролевой модели

Ролевая модель KeyStack реализуется через интеграцию платформы с централизованным сервисом идентификации и аутентификации заказчика, например, Active Directory/LDAP. Роли назначаются пользователям или группам пользователей в централизованном каталоге.

Поведение компонентов зависит от значения параметра enable_rbac_model:

  • enable_rbac_model: "yes" — включена целевая ролевая модель KeyStack. Доступ к компонентам платформы определяется ролью пользователя.

  • enable_rbac_model: "no" — целевая ролевая модель не применяется. Для компонентов используются базовые учётные записи и стандартные права доступа, предусмотренные их конфигурацией.

В ролевой модели KeyStack используются следующие роли:

  • admin — администратор платформы;

  • security_auditor — пользователь с правами просмотра конфигураций, событий и журналов безопасности;

  • reader — пользователь с правами просмотра ресурсов и конфигурации платформы;

  • member — пользователь проекта с правами управления ресурсами в пределах назначенного проекта;

  • operator_vm — оператор виртуальных машин с ограниченными правами просмотра и доступа к ВМ;

  • app_operator — оператор приложения с ограниченным доступом к ВМ приложения;

  • os_operator — оператор ОС с ограниченными правами управления ВМ.

Роли KeyStack получают разные привилегии в компонентах платформы: OpenStack, Портале администратора, GitLab, NetBox, OpenSearch и Grafana.

Роль admin

Администратор платформы управляет конфигурацией регионов, компонентами платформы и виртуальными ресурсами.

При включённой ролевой модели пользователь с ролью admin получает следующие права:

  • OpenStack и Портал администратора

    • управление доменами, проектами, пользователями, группами и назначениями ролей;

    • управление виртуальными машинами, дисками, снимками, образами, сетями, портами, маршрутизаторами и группами безопасности;

    • управление квотами проектов;

    • управление агрегатами хостов и зонами доступности;

    • просмотр журналов аудита;

    • доступ к операциям day-2 через Портал администратора.

  • GitLab

    • доступ к интерфейсу GitLab;

    • роль Maintainer в репозиториях, связанных с развёртыванием и сопровождением региона;

    • роль Reporter в служебных репозиториях платформы;

    • создание коммитов и Merge Request;

    • участие в процессе согласования изменений по правилу второй руки.

  • NetBox

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

  • OpenSearch

    • доступ к интерфейсу логирования и дашбордам;

    • просмотр логов;

    • доступ к административному профилю OpenSearch, если он настроен для роли.

  • Grafana

    • просмотр данных мониторинга;

    • изменение предопределённых и создание новых представлений в интерфейсе Grafana.

Роль security_auditor

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

При включённой ролевой модели пользователь с ролью security_auditor получает следующие права:

  • OpenStack и Портал администратора

    • просмотр доменов, проектов, пользователей, групп и назначений ролей;

    • просмотр виртуальных ресурсов;

    • просмотр системных разделов, доступных для аудита;

    • просмотр журналов аудита.

  • GitLab

    • доступ к интерфейсу GitLab;

    • роль Reporter в доступных репозиториях;

    • просмотр кода, конфигураций, Merge Request и журналов пайплайнов.

  • NetBox

    • доступ только на чтение к инфраструктурным объектам.

  • OpenSearch

    • доступ к дашбордам и логам только на чтение.

  • Grafana

    • просмотр данных мониторинга.

Роль reader

Пользователь с ролью reader просматривает состояние платформы, конфигурацию компонентов и ресурсы без права изменения.

При включённой ролевой модели пользователь с ролью reader получает следующие права:

  • OpenStack и Портал администратора

    • просмотр доменов, проектов, пользователей, групп и назначений ролей;

    • просмотр виртуальных ресурсов;

    • просмотр состояния компонентов платформы.

  • GitLab

    • доступ к интерфейсу GitLab;

    • роль Reporter в доступных репозиториях;

    • просмотр кода, конфигураций, Merge Request и журналов пайплайнов.

  • NetBox

    • доступ только на чтение к инфраструктурным объектам.

  • OpenSearch

    • доступ к дашбордам и логам только на чтение.

  • Grafana

    • просмотр данных мониторинга.

Роль member

Пользователь с ролью member работает с ресурсами в пределах назначенного проекта.

При включённой ролевой модели пользователь с ролью member получает следующие права:

  • OpenStack и Портал администратора

    • создание, просмотр, изменение и удаление виртуальных машин в пределах проекта;

    • создание, просмотр, изменение и удаление дисков, снимков и резервных копий в пределах проекта;

    • создание, просмотр, изменение и удаление образов в пределах проекта;

    • создание, просмотр, изменение и удаление сетей, подсетей и портов в пределах проекта;

    • просмотр типов дисков, flavor и других справочных сущностей, необходимых для работы с ресурсами проекта;

    • доступ к VNC-консоли виртуальных машин.

  • GitLab

    • доступ отсутствует.

  • NetBox

    • доступ отсутствует.

  • OpenSearch

    • доступ отсутствует.

  • Grafana

    • доступ отсутствует.

Роль operator_vm

Пользователь с ролью operator_vm получает ограниченный доступ к виртуальным машинам в пределах назначенного проекта.

При включённой ролевой модели пользователь с ролью operator_vm получает следующие права:

  • OpenStack и Портал администратора

    • просмотр виртуальных машин в пределах проекта;

    • доступ к VNC-консоли виртуальных машин.

  • GitLab

    • доступ отсутствует.

  • NetBox

    • доступ отсутствует.

  • OpenSearch

    • доступ отсутствует.

  • Grafana

    • доступ отсутствует.

Роль app_operator

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

При включённой ролевой модели пользователь с ролью app_operator получает следующие права:

  • OpenStack и Портал администратора

    • просмотр виртуальных машин в пределах проекта;

    • доступ к VNC-консоли виртуальных машин.

  • GitLab

    • доступ отсутствует.

  • NetBox

    • доступ отсутствует.

  • OpenSearch

    • доступ отсутствует.

  • Grafana

    • доступ отсутствует.

Роль os_operator

Пользователь с ролью os_operator получает ограниченные права управления виртуальными машинами в пределах назначенного проекта.

При включённой ролевой модели пользователь с ролью os_operator получает следующие права:

  • OpenStack и Портал администратора

    • просмотр виртуальных машин в пределах проекта;

    • выполнение операций управления состоянием виртуальных машин: запуск, остановка, перезагрузка, пауза, восстановление;

    • доступ к VNC-консоли виртуальных машин;

    • просмотр образов.

  • GitLab

    • доступ отсутствует.

  • NetBox

    • доступ отсутствует.

  • OpenSearch

    • доступ отсутствует.

  • Grafana

    • доступ отсутствует.

Настройка интеграции с LDAP/AD

Для корректной работы ролевой модели требуется сервер LDAP с поддержкой TLS. Доступ осуществляется исключительно по DNS-имени, поскольку TLS-сертификаты выписываются на DNS-имена, а не IP-адреса — это обеспечивает корректную проверку сертификатов.

Сертификат LDAPS добавляется при развёртывании LCM в файл installer/certs/ldaps.pem. Это обеспечивает безопасное соединение между компонентами платформы и каталогом организации.

Конфигурация интеграции описана в разделе Интеграция с LDAP.

Управление секретами

Все критические данные (пароли пользователей, API-токены, сертификаты) хранятся в Vault и автоматически подставляются в конфигурации во время развёртывания. Это предотвращает попадание секретов в код и конфигурационные файлы, доступные широкому кругу пользователей.

Включение ролевой модели в KeyStack

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

Настройка ролевой модели при создании региона описана в разделе:

Ролевая модель в интерфейсах KeyStack

Подробное поведение ролевой модели в интерфейсах KeyStack описано в разделах:

Подключение к интерфейсам OpenSearch, Grafana, NetBox, Horizon и OpenStack CLI описано в разделе: