Управление доступом

Описание

Для управления доступом используется модель RBAC (Role-Based Access Control) — модель, основанная на ролях пользователей. Вместо того чтобы каждый пользователь получал индивидуальный набор прав, права доступа группируются в роли, и пользователи получают доступ на основе своих ролей.

Принцип работы RBAC

1. Определение ролей: Определяются роли, соответствующие различным обязанностям и функциям в системе.
2. Определение прав для ролей: Определяются права, которые должны быть предоставлены каждой роли.
3. Назначение ролей пользователям: Пользователям назначаются роли, соответствующие их обязанностям и функциям.
4. Контроль доступа: Система использует ролевую модель для контроля доступа к ресурсам, основываясь на назначенных ролях пользователей.

Глоссарий

• Пользователи — учётные записи пользователей в базе Deckhouse Commander.
• Группы — учётные записи групп в базе Deckhouse Commander.
• Роли — задают перечень разрешённых действий над определёнными типами ресурсов.
• Назначения — связывают роли с пользователями или группами.
• Ресурсы — объекты Deckhouse Commander, к которым возможно применение прав доступа.
• Права — описывают конкретные действия, которые могут быть выполнены над ресурсами.

Поддерживаемые ресурсы Deckhouse Commander

• users — пользователи.
• groups — группы.
• globalroles — глобальные роли.
• globalrolebindings — глобальные назначения.
• workspaces — рабочие пространства.
• workspaceroles — роли рабочих пространств.
• workspacerolebindings — назначения рабочих пространств.
• clusters — кластеры.
• clustertemplates — шаблоны кластеров.
• authtokens — токены.
• catalogs — инвентарь.
• projects — проекты.
• projectrolebindings — назначения участников проекта.
• billingdashboard — биллинг: дашборд и аналитика.
• billingtariffs — биллинг: управление тарифами.
• billingresources — биллинг: управление вычислительными классами и классами хранилища.
• billingreports — биллинг: управление отчётами.

Только просмотр

• workspaceroles/audit — история изменений ролей рабочих пространств.
• workspacerolebindings/audit — история изменений назначений рабочих пространств.
• clusters/audit — история изменений кластеров.
• clustertemplates/audit — история изменений шаблонов.
• authtokens/audit — история изменений токенов.
• catalogs/audit — история изменений инвентаря.
• projects/audit — история изменений проектов.

Роли и назначения

Глобальные роли и назначения действуют на глобальном уровне для всех ресурсов Deckhouse Commander, а Kubernetes ресурсы создаются во всех кластерах под управлением Deckhouse Commander. Для каждой роли формируется ClusterRole с заданными правилами Kubernetes и для каждого назначения роли формируется ClusterRoleBinding. Ресурсы транслируются с префиксом d8:commander:. Например, роль viewer будет создана во всех кластерах как ClusterRole/d8:commander:viewer. Это же правило работает для назначения прав и соответствующего ресурса ClusterRoleBinding.

Роли и назначения рабочего пространства (РП) действуют на уровне конкретного РП, а Kubernetes ресурсы создаются во всех кластерах данного РП. Для каждой роли формируется ClusterRole с заданными правилами Kubernetes и для каждого назначения роли формируется ClusterRoleBinding. Ресурсы уровня РП транслируются с префиксом d8:commander:workspace:, например роль viewer будет создана во всех кластерах РП как ClusterRole/d8:commander:workspace:viewer. Это же правило работает для назначения прав в РП и соответствующего ресурса ClusterRoleBinding.

В кластерах создается специальная группа ресурсов «Права доступа», которая автоматически заполнена актуальными ролями и назначениями (как глобальными, так и в рамках РП). Эти манифесты — ClusterRole и ClusterRoleBinding — актуализируются в кластерах с помощью агента (модуль commander-agent). Все назначения, изменения и удаления прав в кластерах актуализируются автоматически. Интерфейс платформы (Кластер → вкладка «Администрирование») подстраивается под права пользователя в этом кластере.

Пользовательский интерфейс

Панель настройки глобальных прав

На данную страницу можно попасть из панели рабочих пространств (/workspaces), выбрав пункт меню «Пользователи и права» в шапке.

• Вкладка «Пользователи» — просмотр списка пользователей и их групп, зарегистрированных в Deckhouse Commander.
• Вкладка «Группы» — просмотр списка групп и их членов, зарегистрированных в Deckhouse Commander.
• Вкладка «Роли» — управление ролями.
• Вкладка «Назначения» — управление назначениями.

Панель настройки прав рабочего пространства

На данную страницу можно попасть, выбрав пункт меню «Пользователи и права» в шапке внутри рабочего пространства.

Содержимое аналогично панели настройки глобальных прав, но для пользователей и групп РП.

Конфигурация

Требования для работы прав доступа в Deckhouse Commander

• Настроенная интеграция с внешним IdP через dex-provider в управляющем кластере.
• Роль и назначение¹ для пользователя или группы созданное в интерфейсе Deckhouse Commander.
• Пользователь, входящий в систему через Dex.

Для доступа в прикладные кластеры Commander использует ту же учётную запись. О том, как выстроена доверительная связка и какие ресурсы создаются автоматически, см. Аутентификация в прикладных кластерах через DexProvider.

Первичная настройка прав доступа

На чистой установке, когда полномочия администратора ещё не назначены, Deckhouse Commander автоматически перенаправляет первого авторизовавшегося пользователя на страницу первичной настройки (/bootstrap). Страница запрашивает токен первичной настройки — одноразовое значение с ограниченным сроком действия, которое генерируется при развёртывании и хранится в секрете bootstrap-token в неймспейсе d8-commander.

Чтобы прочитать значение токена, выполните:

$ d8 k -n d8-commander get secret bootstrap-token -o jsonpath='{.data.token}' | base64 -d

Либо откройте секрет в веб-интерфейсе DKP. Введите значение токена на странице настройки и нажмите «Получить доступ». Права администратора выдаются немедленно, после чего токен становится недействительным.

После этого можно переходить к настройке прав доступа через веб-интерфейс.

Восстановление утраченного доступа администратора

Если административный доступ к Deckhouse Commander утрачен (например, при смене IdP или случайном удалении роли), восстановите его с помощью токена первичной настройки:

1. Удалите секрет bootstrap-token в неймспейсе d8-commander:

   $ d8 k -n d8-commander delete secret bootstrap-token

2. Deckhouse Commander сгенерирует новый токен и перезапустится автоматически.

3. Прочитайте новое значение токена и откройте /bootstrap в веб-интерфейсе Deckhouse Commander.

4. Введите токен и нажмите «Получить доступ». Права администратора восстановлены, токен становится недействительным.

Настройка прав доступа в веб-интерфейсе Deckhouse Commander

Для настройки прав доступа необходимо выполнить следующие шаги:

1. Открыть панель настройки прав.
2. Перейти на вкладку «Роли» и создать роль:
   1. Нажать на кнопку «Добавить глобальную роль».
   2. Задать уникальное имя роли и комментарий.
   3. Нажать на кнопку «Добавить правило Commander».
   4. Указать права и ресурсы.
   5. При необходимости можно создать несколько правил.
   6. Нажать кнопку «Сохранить».
3. Перейти на вкладку «Назначения» и создать назначение:
   1. Нажать на кнопку «Добавить глобальное назначение».
   2. Задать имя или включить переключатель «Генерировать из роли». В этом случае для генерации имени будут использованы имя роли и случайный набор букв.
   3. Выбрать роль.
   4. Выбрать пользователей или группы. Если пользователь или группа ещё не существуют в Deckhouse Commander, можно указать их вручную в формате user:<login> / group:<name>.
   5. Нажать кнопку «Сохранить».

Права применены.

Права доступа в проектах

Модель прав доступа в проектах Deckhouse Commander двухуровневая:

1. Глобальные роли Commander определяют полномочия над проектами как ресурсами Commander: доступ к разделу «Проекты», создание, изменение и удаление проектов, управление участниками проектов.
2. Роли внутри проекта определяют полномочия над ресурсами проекта в прикладном кластере. Назначения транслируются в манифест AuthorizationRule, который применяет в кластере модуль multitenancy-manager как часть ресурсов проекта.

Ресурсы Commander для управления проектами

К перечню поддерживаемых ресурсов относятся:

• projects — проекты.
• projectrolebindings — назначения участников проекта. Доступ к управлению projectrolebindings конкретного проекта проверяется по участию пользователя в роли Admin этого проекта, а не только по глобальной роли.

Раздел «Проекты» отображается в веб-интерфейсе только пользователям, у которых есть хотя бы verb get на ресурсе projects, и при условии, что в Deckhouse Commander включена функциональность проектов.

Предустановленные глобальные роли

Deckhouse Commander поставляет две предустановленные глобальные роли для работы с проектами:

• autogenerated-projects-user — роль с правилом verbs: ["get"], resources: ["projects"]. Автоматически назначается пользователю, которого добавили хотя бы в один проект, через единое назначение уровня рабочего пространства autogenerated-projects-users. Даёт доступ к разделу «Проекты» и к страницам проектов, но не позволяет создавать, изменять и удалять проекты, а также управлять участниками проектов, в которых пользователь не состоит в роли Admin. Роль и её назначение форсируются Deckhouse Commander: при ручном удалении они будут пересозданы при следующем добавлении участника в любой проект.
• projects-admin — роль с правилом verbs: ["*"], resources: ["projects"]. Предназначена для пользователей, которым требуется создавать, изменять и удалять проекты. Назначается вручную администратором системы в разделе «Пользователи и права».

Для более тонкой настройки администратор системы может создавать собственные глобальные роли с произвольными комбинациями verbs на ресурсах projects и projectrolebindings.

Видимость проектов в списке

Состав проектов, доступных пользователю в списке, определяется его правами на ресурс projects:

Роли внутри проекта

В каждом проекте доступны четыре предустановленные роли. Их имена в Commander соответствуют значениям spec.accessLevel в манифесте AuthorizationRule, формируемом для каждой роли проекта:

Перечень Kubernetes-ресурсов и действий, соответствующих каждому accessLevel, определяет модуль user-authz.

Для каждой роли проекта Commander создаёт в прикладном кластере отдельный AuthorizationRule (admins, editors, privileged-users, users). Участники перечисляются в spec.subjects[]. Манифесты доставляются агентом Deckhouse Commander.

Разделение ответственности

• Администратор системы управляет параметрами проекта на вкладке «Конфигурация» страницы проекта, включая поле «Администраторы».
• Администратор проекта (пользователь в роли Admin) управляет назначениями User, PrivilegedUser и Editor на вкладке «Доступы» страницы проекта. Назначения роли Admin на этой вкладке отображаются в режиме только для чтения и изменяются через вкладку «Конфигурация».
• Пользователи в ролях Editor, PrivilegedUser, User вкладку «Доступы» не видят.

Если один пользователь совмещает обе функции (например, администратор системы одновременно назначен Admin проекта), в интерфейсе ему доступны обе вкладки.

Сопровождение форс-назначения autogenerated-projects-users

При добавлении участника в любой проект Commander добавляет его как subject в единое назначение autogenerated-projects-users уровня рабочего пространства. На одно рабочее пространство создаётся одно такое назначение, в котором аккумулированы участники всех проектов рабочего пространства.

При удалении участника из проекта subject из autogenerated-projects-users не удаляется автоматически, чтобы не отзывать доступ у пользователя, который остаётся участником других проектов. При необходимости subject может удалить вручную администратор системы в разделе «Пользователи и права». Если назначение autogenerated-projects-users удалено целиком, оно будет пересоздано при следующем добавлении участника в любой проект рабочего пространства.

Валидация

• В проекте должен быть назначен хотя бы один администратор (роль Admin): удалить последнее назначение Admin нельзя.
• При множественном членстве пользователя (через несколько групп или напрямую и через группу) итоговые права в кластере определяются модулем user-authz по приоритету Admin > Editor > PrivilegedUser > User.

Ограничения

• Проекты типа deckhouse — это проекты DKP, созданные непосредственно в прикладном кластере и не находящиеся под управлением Deckhouse Commander. В списке проектов они помечаются значком. В веб-интерфейсе Deckhouse Commander для таких проектов не предусмотрены форма редактирования и вкладка «Доступы» — управление такими проектами выполняется непосредственно в Deckhouse с помощью модуля multitenancy-manager, в том числе через манифест AuthorizationRule.
• В этой версии управление участниками проектов и предустановленными ролями (autogenerated-projects-user, projects-admin) возможно только через веб-интерфейс Deckhouse Commander.

Аудит

Все изменения ролей и назначений логируются. Информация доступна во вкладке «История изменений» на уровне РП.