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

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

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

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

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

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

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

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

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

Ролевая модель платформы KeyStack состоит из четырёх базовых ролей:

  • admin — администратор платформы. Эта роль даёт максимальные привилегии доступа во всей платформе: развёртывает и конфигурирует регионы, может проводить все day-2 операции через LCM, обладает всеми правами для работы с виртуальными элементами платформы.

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

  • reader — непривилегированный оператор платформы. Роль предоставляет доступ только на чтение для контекста системы, домена или проекта. Даёт возможность просмотра конфигурации региона, компонентов региона, виртуальных элементов.

  • member — учётная запись пользователя платформы. Даёт пользователю ограниченные права на использование ресурсов в рамках проекта (тенанта). Эта роль используется для доступа к ресурсам, принадлежащим проекту, с возможностью взаимодействия с ними, но без административных привилегий. Например, пользователи с ролью member в проекте могут просматривать, создавать и удалять ВМ.

Дополнительная роль, которая может быть использована на усмотрение администратора:

  • operator_vm — оператор виртуальных машин. Роль предоставляет права на чтение и доступ через VNC к виртуальным машинам в пределах назначенного проекта (или проектов) домена компании. Назначение роли может быть реализовано в формате точечной привязки к группе виртуальных машин, объединённых общим тегом, например, тегом ОС операционной системы.

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

Роли KeyStack получают различные привилегии в компонентах платформы. Например, роль admin KeyStack соответствует роли Owner в GitLab, а роль reader — роли Reporter.

Сопоставление ролей KeyStack

Сопоставление ролей KeyStack

Роль admin

Администратор платформы, который может:

  • устанавливать и развёртывать регионы,

  • менять конфигурацию регионов и компонентов платформы в регионах,

  • проводить все day-2 операции через LCM,

  • управлять виртуальными элементами платформы.

Обладает следующими привилегиями доступа к компонентам платформы:

  • OpenStack (включая AdminUI)

    • Admin в проекте admin домена OpenStack Default и внешнем домене:

      • CRUD доменов OpenStack.

      • CRUD проектов OpenStack.

      • CRUD агрегатов и зон доступности OpenStack.

      • CRUD ролей OpenStack (но не набора привилегий для ролей).

      • Сопоставление роли OpenStack группе из службы каталогов в проектах и доменах (конфигурация компоненты OpenStack).

    • Admin в проекте OpenStack:

      • CRUD виртуальных элементов платформы (виртуальные машины, диски, образы, сетевые элементы и прочее).

      • Создание, запуск, остановка процедур DRS.

      • Запуск процедур миграции, эвакуации.

  • GitLab

    • Maintainer в проектах:

      • project_k/deployments/gen-pwd

      • project_k/deployments/<имя региона>

      • project_k/services/backup

      • project_k/services/upgrade

    • Guest в проектах:

      • project_k/ci/keystack

      • project_k/ci/kolla

      • project_k/deployments/bifrost

      • project_k/keystack

      • project_k/services/baremetal

      • project_k/services/dib

  • NetBox

    • CRUD инфраструктурных элементов платформы (гипервизоры, интерфейсы, IP адреса, и прочее).

  • Мониторинг

    • Просмотр и чтение информации мониторинга, протоколов и событий алертинга.

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

Роль security_auditor

Специалист информационной безопасности, который может:

  • просматривать конфигурацию регионов и компонентов платформы в регионах,

  • просматривать результаты day-2 операций,

  • просматривать информацию о виртуальных элементах платформы,

  • просматривать события аудита.

Обладает следующими привилегиями доступа к компонентам платформы:

  • OpenStack (включая AdminUI)

    • Reader в проекте admin домена OpenStack Default и внешнем домене:

      • Просмотр информации о доменах OpenStack.

      • Просмотр информации о проектах OpenStack.

      • Просмотр информации о сопоставлении ролей OpenStack группам AD в проектах и доменах.

    • Reader в проекте OpenStack:

      • Просмотр информации о виртуальных элементах платформы (виртуальные машины, диски, образы, сетевые элементы и прочее).

  • GitLab

    • Guest во всех проектах.

  • NetBox

    • Просмотр информации об инфраструктурных элементах платформы.

  • Мониторинг

    • Просмотр и чтение информации мониторинга, протоколов и событий алертинга.

Роль reader

Специалист с этой ролью может:

  • просматривать конфигурацию регионов и компонентов платформы в регионах,

  • просматривать результаты day-2 операций,

  • просматривать информацию о виртуальных элементах платформы,

  • отслеживать статус здоровья облака.

Обладает следующими привилегиями доступа к компонентам платформы:

  • OpenStack (включая AdminUI)

    • Reader в домене OpenStack Default:

      • Просмотр информации о доменах OpenStack.

      • Просмотр информации о проектах OpenStack.

      • Просмотр информации о сопоставлении ролей OpenStack группам AD в проектах и доменах.

    • Reader в проекте OpenStack:

      • Просмотр информации о виртуальных элементах платформы (виртуальные машины, диски, образы, сетевые элементы и прочее).

  • GitLab

    • Guest во всех проектах.

  • NetBox

    • Просмотр информации об инфраструктурных элементах платформы.

  • Мониторинг

    • Просмотр и чтение информации мониторинга, протоколов и событий алертинга.

Роль member

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

Обладает следующими привилегиями доступа к компонентам платформы:

  • OpenStack (исключая AdminUI)

    • Member в проекте OpenStack:

      • CRUD виртуальных элементов платформы (виртуальные машины, диски, образы, сетевые элементы и прочее).

      • Просмотр информации обо всех ресурсах системы.

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

      • Просмотр групп безопасности.

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

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

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

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

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

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

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

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

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