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

Описание

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

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

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

Глоссарий

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

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

• users — пользователи.
• groups — группы.
• globalroles — глобальные роли.
• globalrolebindings — глобальные назначения.
• globalserviceaccounts — глобальные сервисные аккаунты.
• workspaces — рабочие пространства.
• workspaceroles — роли рабочих пространств.
• workspacerolebindings — назначения рабочих пространств.
• workspaceserviceaccounts — сервисные аккаунты рабочих пространств.
• clusters — кластеры.
• changerequests — запросы на изменения кластеров.
• clustertemplates — шаблоны кластеров.
• publicclustertemplates — публикация версий шаблонов кластеров; ресурс доступен только в глобальных ролях.
• catalogs — инвентарь.
• projects — проекты.
• projectrolebindings — назначения участников проекта.
• billingdashboard — биллинг: дашборд и аналитика.
• billingtariffs — биллинг: управление тарифами.
• billingresources — биллинг: управление вычислительными классами и классами хранилища.
• billingreports — биллинг: управление отчётами.
• billingaccounts — биллинг: управление лицевыми счетами.
• billingtransactions — биллинг: операции по лицевому счёту (пополнение, списание и история).

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

• workspaceroles/audit — история изменений ролей рабочих пространств.
• workspacerolebindings/audit — история изменений назначений рабочих пространств.
• globalserviceaccounts/audit — история изменений глобальных сервисных аккаунтов.
• workspaceserviceaccounts/audit — история изменений сервисных аккаунтов рабочих пространств.
• clusters/audit — история изменений кластеров.
• clustertemplates/audit — история изменений шаблонов.
• catalogs/audit — история изменений инвентаря.
• projects/audit — история изменений проектов.
• billingaccounts/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.
• Вкладка «Сервисные аккаунты» — управление глобальными сервисными аккаунтами и их API-ключами.
• Вкладка «Роли» — управление ролями.
• Вкладка «Назначения» — управление назначениями.

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

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

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

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

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

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

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

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

Сервисные аккаунты

Сервисный аккаунт — это машинная учётная запись для API интеграции. Он является субъектом назначений наравне с пользователем и группой и получает права только из назначенных ему ролей. Запросы аутентифицируются API-ключами аккаунта: ключ подтверждает, какой аккаунт обращается к API, и не содержит собственных прав, области видимости или режима доступа.

Deckhouse Commander поддерживает два вида сервисных аккаунтов:

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

Имя аккаунта неизменяемо и соответствует формату DNS-имени: от 3 до 63 символов, строчные латинские буквы, цифры и дефис, первый и последний символ — буква или цифра. Имена с префиксом migrated-token- зарезервированы для аккаунтов, созданных при миграции токенов доступа. Имена субъектов разных видов не конфликтуют друг с другом, как и имена сервисных аккаунтов разных рабочих пространств.

Сервисные аккаунты как субъекты назначений

В форме назначения роли сервисные аккаунты выбираются в том же поле, что пользователи и группы. Выберите аккаунт из списка или введите serviceaccount:<ИМЯ>, где <ИМЯ> — точное имя аккаунта. В списке показан вид аккаунта, поэтому одноимённые аккаунты разных видов различимы; если введённому имени соответствует несколько аккаунтов, выберите нужный из списка.

• Глобальное назначение принимает только глобальные сервисные аккаунты.
• Назначение рабочего пространства принимает глобальные сервисные аккаунты и сервисные аккаунты этого РП.
• Назначение принимает только существующий аккаунт и никогда не создаёт его неявно.

Все ключи одного аккаунта получают одинаковые права — объединение назначенных аккаунту ролей. Отзыв ключа, снятие назначения и удаление аккаунта действуют со следующего запроса.

Права на управление сервисными аккаунтами

Управление аккаунтами и их ключами доступно только в веб-интерфейсе и не публикуется в API интеграции, поэтому сервисный аккаунт не может выпускать ключи сам себе.

Ресурсы globalserviceaccounts и globalserviceaccounts/audit глобальны по своей природе: права на них даёт только глобальное назначение. Назначение рабочего пространства не даёт их никогда, даже если эти ресурсы в нём перечислены.

Удаление сервисного аккаунта

Удаление аккаунта архивирует его, отзывает все его активные ключи и убирает его из всех назначений, где он был субъектом. Действие необратимо: запросы со старыми ключами перестают работать сразу.

Имя удалённого аккаунта можно использовать снова. Новый аккаунт с тем же именем — это новая идентичность: он не наследует роли удалённого, а в истории изменений обе записи сохраняются раздельно.

Удаление рабочего пространства удаляет его сервисные аккаунты вместе с их ключами и назначениями.

Сервисные аккаунты и доступ к проектам

Сервисный аккаунт управляет проектами через ресурсы Deckhouse Commander projects и projectrolebindings теми же verbs, что и пользователь. При этом действуют два ограничения.

• Сервисный аккаунт не становится участником проекта. ProjectRoleBinding принимает только пользователей и группы, поэтому аккаунт с правами на projectrolebindings меняет состав других субъектов, но сам субъектом не становится.
• Сервисный аккаунт не получает доступ к ресурсам внутри кластера проекта. Для рабочих нагрузок используйте Kubernetes ServiceAccount проекта.

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

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

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

Ресурсы Deckhouse 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:

Держатели лицевых счетов

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

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

Видимость лицевых счетов и их операций определяется правами на ресурсы billingaccounts/billingtransactions:

Право billingdashboard в этой роли сужается тем же членством: держатель лицевого счёта видит на дашборде данные только по рабочим пространствам своих счетов.

Список рабочих пространств, не привязанных ни к одному лицевому счёту, доступен только тем, кто может создавать счета (право create на billingaccounts): именно они выполняют привязку, и такой список не раскрывает держателю счёта чужие рабочие пространства.

Назначение держателей лицевого счёта выполняется в форме счёта (создание/редактирование), поле «Держатели». Снятие последнего держателя убирает соответствующий доступ.

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

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

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

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

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

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

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

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

При добавлении участника в любой проект Deckhouse 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.

Согласование создания кластеров

Когда в рабочем пространстве включено согласование создания кластеров, установка кластера порождает запрос на согласование, который кто-то должен одобрить или отклонить. Доступ к таким запросам определяется ресурсом changerequests: он входит в список поддерживаемых ресурсов и действует на уровне рабочего пространства.

Предустановленная роль и назначение

Deckhouse Commander поставляет предустановленную роль для принятия решений по запросам на создание кластеров:

• cluster-change-approver — роль с правилами verbs: ["get", "update"], resources: ["changerequests"] и verbs: ["get"], resources: ["clusters"]. Она автоматически назначается через назначение уровня рабочего пространства autogenerated-cluster-change-approvers пользователям и группам, выбранным как согласующие на странице «Параметры» рабочего пространства. Согласовать запрос может любой участник назначенной группы.

Роль и её назначение форсируются Deckhouse Commander при сохранении согласующих: выбор согласующего автоматически выдаёт необходимые права, а удаление пользователя или группы из списка их отзывает. Это штатный способ назначить согласующего — права и назначение здесь одно и то же действие, отдельная ручная выдача прав не нужна.

Состав согласующих правится на странице «Параметры» рабочего пространства, в разделе «Согласование создания кластеров». Этот раздел управляется ресурсом workspacerolebindings: get — чтобы видеть, update — чтобы менять. То же назначение можно править и через штатный редактор назначений — это тот же список субъектов.

Согласующими могут быть только пользователи и группы. Сервисный аккаунт принимать решение по запросу не может: API интеграции такие запросы не одобряет.

Согласующие по другой роли

Право и есть назначение: согласующими субъектов делает любая роль с правом update на changerequests, а не только предустановленная. Поле «Согласующие» это отражает — оно строится по правам, а не по одному назначению:

• субъекты назначения autogenerated-cluster-change-approvers показываются как редактируемые записи;
• субъекты, получившие право другой ролью рабочего пространства, показываются неудаляемыми записями с подсказкой, какая роль дала право. Снимать их нужно в управлении доступом, а не в этом поле;
• из них показываются только те, кто присутствует в списках «Пользователи» и «Группы» этого рабочего пространства, поэтому согласующие других рабочих пространств в поле не утекают;
• глобальные назначения ролей в поле не показываются вовсе. Право они дают точно так же, поэтому глобальная роль с правом update на changerequests делает своих субъектов согласующими во всех рабочих пространствах, и это поле такого субъекта не покажет.

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

Самоодобрение и доступ только на просмотр

• Инициатор, у которого есть право update на changerequests, может одобрить собственный запрос. Инициатор без этого права — не может: попытка отклоняется.
• Пользователь, у которого есть только право get на changerequests, — наблюдатель: он видит очередь и счётчик, но кнопок решения у него нет.
• Права на изменение кластеров согласующим не нужны. Для изучения конфигурации требуется право get на clusters, которое входит в предустановленную роль. Пользователь, который является согласующим, но не имеет права update на clusters, может одобрить установку, но не может редактировать конфигурацию кластера и не получает на странице кластера кнопку подтверждения изменений в ручном режиме — для неё нужно право update на clusters.

Аудит

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