Как происходит назначение прав доступа

Цепочка событий при назначении прав пользователю или группе.

Краткий обзор процесса #

Если вы ещё не знакомы с особенностями ресурсов для управления правами доступа в платформе «Штурвал», начните с ознакомления со статьей Кастомные ресурсы для управления правами доступа.

1. Администратор назначает права в GUI (пользователь или группа + один или несколько наборов доступов).
2. Backend создаёт или обновляет Scope (граница уровня) и UserRole / GroupRole (субъект + список Permission).
3. Оператор согласования прав (shturval-permission-operator, Deployment shturval-permission-operator-controller) выполняет reconcile:
   • Permission → ClusterRole в кластере управления и клиентских кластерах;
   • UserRole / GroupRole → применение через плагины (Argo CD, Kubeflow).
4. Параллельно оператор обновляет OPA bundle (HTTP /bundle, порт 8082) — данные для Authz (OPA) при проверке запросов в Backend.
5. Статус отражается в UserRole/GroupRole.status и в GUI.

Схема потока #

Подробные диаграммы reconcile — в Операторе согласования прав.

Пошаговый процесс #

Шаг 1. Действие в интерфейсе #

Администратор на странице Управление ролями:

1. Выбирает уровень (Платформа, Тенант, Кластер или Неймспейс).
2. Нажимает + рядом с «Пользователи» или «Группы».
3. Указывает имя пользователя или группы (из LDAP или вручную).
4. Выбирает один или несколько наборов доступов.
5. Нажимает Сохранить.

Подробнее: Назначение прав доступа.

Шаг 2. Область и привязка (Scope, UserRole / GroupRole) #

Backend сохраняет назначение в виде кастомных ресурсов Kubernetes (API-группа permissions.shturval.tech, неймспейс shturval-backend кластера управления).

2a. Область (Scope) #

Backend создаёт или использует Scope, соответствующий выбранному уровню (платформа, тенант, кластер, неймспейс). Границы области задаются полем spec.objects.

На уровне Тенант связанный Scope также создаётся оператором из объекта Tenant (имя scope совпадает с именем тенанта).

2b. Привязка (UserRole / GroupRole) #

• UserRole — назначение пользователю;
• GroupRole — назначение группе.

В спецификации указываются:

Обратите внимание! после создания объекта spec.username (UserRole) и spec.claim (GroupRole) нельзя изменить — validating webhook отклонит Update.

Подробнее: Кастомные ресурсы для управления правами доступа.

Шаг 3. Согласование наборов (Permission) #

Каждый набор доступов в платформе соответствует CR Permission. Его согласует PermissionReconciler оператора shturval-permission-operator:

• granted_platform_permissions → агрегирующий ClusterRole на платформе (префикс имён platform:);
• granted_cluster_rules → ClusterRole в клиентских кластерах (префикс shturval:); доступ к API клиентского кластера — через Secret <имя-кластера>-kubeconfig, ключ value.

События CAPI Cluster (готовность control plane, удаление, пауза) инициируют повторное согласование затронутых Permission.

Шаг 4. Согласование привязки через shturval-permission-operator #

UserRoleReconciler и GroupRoleReconciler (оператор shturval-permission-operator, Deployment shturval-permission-operator-controller) выполняют reconcile привязки:

1. Читают связанный Scope и наборы Permission из spec.permissions.
2. Определяют целевые кластеры по Scope (см. таблицу уровней ниже).
3. Последовательно вызывают плагины для каждого permission:
   • RBAC — привязка субъекта к ClusterRole, созданным на шаге 3;
   • Argo CD, Kubeflow, tenant — если соответствующие поля заданы в Permission.
4. При ошибке плагина — немедленный повтор reconcile; при успехе — обновление status.

Подробнее об архитектуре оператора: Оператор согласования прав (permissions operator).

Шаг 5. Плагины Kubeflow и Argo CD #

Если в наборе доступов (Permission) указаны роли Kubeflow (kubeflow-admin, kubeflow-edit, kubeflow-view), плагин Kubeflow применяет соответствующие права:

• Платформа — профили (неймспейсы) во всех кластерах;
• Кластер — профили кластера;
• Неймспейс — профиль одного неймспейса.

Если указана роль Argo CD (admin, edit, view), плагин Argo CD создаёт или обновляет роли в проектах:

• Платформа — все проекты;
• Кластер — проекты кластера;
• Неймспейс — проект одного неймспейса.

Шаг 6. Статус применения #

Оператор записывает результат в UserRole.status / GroupRole.status: вложенная карта status.permissions → кластер или платформа → имя плагина → PluginApplyStatus.

GUI отображает сводный статус по каждому целевому контуру:

Для отладки: kubectl describe userrole <имя> -n shturval-backend (или grouprole).

Зависимости от уровня назначения #

Границы уровня задаёт Scope, на который ссылается UserRole.spec.scope / GroupRole.spec.scope.

Обратите внимание! объекты кластеров (Cluster, Machine и др.) и объекты permissions.shturval.tech хранятся в кластере управления. Поэтому даже при назначении на уровне «кластер» или «неймспейс» часть прав применяется в кластере управления.

Типичные причины сбоев #

Подробнее: Траблшутинг доступа.