Архитектура модулей доступа в платформе

Как устроена система доступа.

Компоненты #

• Аутентификация — проверка личности пользователя через LDAP, AD или OIDC;
• Авторизация — проверка прав на доступ к ресурсам (RBAC);
• Модуль управления доступом — применение назначений в кластерах и неймспейсах.

Аутентификация #

Аутентификация в платформу доступна с помощью внутреннего провайдера Authn. Дополнительно можно подключить внешние провайдеры по протоколу OAuth OIDC 2.0: Keycloak или Blitz.

Схема аутентификации #

Процесс аутентификации:

1. Проверка внешнего провайдера: при входе неаутентифицированного пользователя система проверяет наличие настроенного внешнего OIDC-провайдера.

2. Выбор провайдера:

   • Если внешний провайдер не настроен — отображается форма ввода логина/пароля (внутренний провайдер Authn).
   • Если внешний провайдер настроен:
     • При установленном флаге «использовать только внешний провайдер» — пользователь перенаправляется на внешний провайдер.
     • Если флаг не установлен — пользователю предлагается выбор между внутренним и внешним провайдером.

3. Аутентификация:

   • Внутренний провайдер: пользователь вводит логин и пароль в форме платформы.
   • Внешний провайдер: пользователь перенаправляется на страницу внешнего сервиса (Keycloak, Blitz и т.д.), проходит аутентификацию, после чего система получает внешний токен.

4. Выдача токена: независимо от выбранного метода аутентификации, платформа выписывает внутренний токен для доступа к ресурсам платформы.

Возможности:

• Использование внутреннего провайдера Authn для интеграции с LDAP.
• Подключение внешних OAuth OIDC 2.0 провайдеров Keycloak и Blitz.
• Гибкая настройка: можно использовать только внешний провайдер или предоставить пользователю выбор.
• Единый внутренний токен для всех методов аутентификации, обеспечивающий консистентность системы доступа.

Настройка внешних провайдеров: см. страницу Внешние провайдеры аутентификации (включает сценарии подключения Keycloak и Blitz).

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

Система управления доступом платформы построена на основе RBAC (Role-Based Access Control) и использует кастомные ресурсы Kubernetes для хранения назначений прав и их синхронизации в кластеры.

Схема управления доступом #

Компоненты системы:

1. Аутентификация (Auth): обрабатывает все запросы от пользователей через браузер, проверяет личность пользователя и выписывает внутренний токен.

2. Frontend (Front): взаимодействует с браузером и передаёт запросы к сервисам мониторинга (Grafana).

3. Backend (Back): обрабатывает запросы от браузера и использует Authz (OPA) для проверки прав доступа. Выполняет операции создания, изменения и удаления объектов Scope и Permission.

4. Авторизация (Authz, OPA): компонент авторизации на базе Open Policy Agent, который проверяет права пользователя на выполнение операций.

5. STP (Security Token Processor): центральный компонент системы управления доступом:

   • Получает решения об авторизации от Back (Authz OPA) и от VMS (Victoria Metrics Authz Proxy);
   • Выполняет reconcile (синхронизацию) объектов UserRole и GroupRole;
   • Отправляет результаты синхронизации в Kube API для применения прав на уровне платформы.

6. UserRole и GroupRole: кастомные ресурсы (API-группа permissions.shturval.tech), которые хранят назначения прав пользователям и группам. Связаны с объектами Scope и Permission.

7. Scope и Permission: определяют области применения и конкретные разрешения. Backend управляет этими объектами (create/patch/delete), а STP использует их при reconcile.

Применение прав:

• На уровне платформы: STP синхронизирует UserRole/GroupRole в Kube API платформы, который применяет Kube RBAC (platform permissions) для доступа к ресурсам платформы.

• На уровне кластера: права синхронизируются в Kube API клиентского кластера, который применяет Kube RBAC (cluster permissions) для доступа к ресурсам кластера.

Интеграция с сервисами:

• Grafana: получает запросы через Frontend; доступ контролируется через систему авторизации.
• Victoria Metrics: доступ к метрикам контролируется через VMS (Victoria Metrics Authz Proxy), который взаимодействует со STP.
• Kubeflow: доступ к профилям контролируется через роли Kubeflow, заданные в наборах доступов.
• ArgoCD: доступ к проектам и приложениям контролируется через Kubernetes RBAC в клиентских кластерах; настройки ArgoCD синхронизируются через argocd-rbac-cm и AppProject.

Процесс синхронизации:

1. Администратор создаёт или изменяет назначения прав через графический интерфейс (Backend создаёт/изменяет UserRole/GroupRole).
2. STP выполняет reconcile: читает UserRole/GroupRole и связанные Permissions, объединяет разрешения из всех назначенных наборов.
3. STP отправляет результаты в Kube API платформы и клиентских кластеров.
4. Kubernetes RBAC применяет права в соответствующих кластерах и неймспейсах.

Подробнее о кастомных ресурсах: UserRole, GroupRole и Permissions.

Схема авторизации запросов #

Взаимодействия на схеме авторизации:

1. Пользователь в браузере обращается к веб‑интерфейсу платформы (Frontend), передавая внутренний токен, выданный модулем аутентификации.
2. Frontend проксирует запросы к Backend, а также в отдельные сервисы (Grafana, Victoria Metrics, Kubeflow, ArgoCD) через настроенные точки интеграции.
3. Backend перед выполнением операции запрашивает решение у Authz (OPA) по текущему пользователю, набору его ролей и целевому ресурсу/действию.
4. Authz (OPA) использует правила и данные о назначениях прав (Scope, Permission, UserRole, GroupRole), которые поддерживаются в актуальном состоянии компонентом STP (Security Token Processor).
5. STP периодически считывает объекты UserRole/GroupRole/Permission из кластера управления, агрегирует разрешения и синхронизирует их в:
   • Kube API платформы — для прав на уровне платформы;
   • Kube API клиентских кластеров — для прав на уровне кластеров и неймспейсов.
6. Для доступа к метрикам Victoria Metrics решение об авторизации принимает прокси VMS, который также опирается на данные, синхронизированные STP (связка пользователей/тенантов/кластеров).
7. После положительного решения Authz/OPA (и, при необходимости, VMS) Backend выполняет запрошенную операцию или отдаёт данные пользователю; при отказе — возвращает ошибку авторизации.

Уровни доступа #

Права назначаются на уровнях:

• Платформа — доступ к кластеру управления и клиентским кластерам в целом;
• Тенант — доступ ко всем объектам тенанта;
• Кластер — доступ к конкретному кластеру (управления или клиентскому);
• Неймспейс — доступ к неймспейсу в кластере.

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

• На уровне платформы: см. Назначение прав доступа в разделе «Администратору платформы».
• На уровне кластера: см. Управление доступом в кластере в разделе «Администратору кластера».

Синхронизация #

Назначения прав применяются в кластер управления и клиентские кластеры. Статус применения отображается в интерфейсе (успешно / ошибка / не требуется).