RBAC

Role-Based Access Control — роли, скоупы и управление доступом по принципу наименьших привилегий

🔧 Team и выше

Обзор

FlowLink RBAC управляет доступом к ресурсам платформы через роли и скоупы. Каждый пользователь привязан к роли, и каждый API-запрос проверяется на наличие соответствующих разрешений. Система поставляется с тремя встроенными ролями (admin, operator, viewer) и поддерживает создание произвольного числа кастомных ролей для реализации принципа наименьших привилегий.

RBAC Пайплайн

API-запрос → JWT auth → извлечение role + scopes → проверка разрешений → handler / 403

Ключевые возможности

Три предустановленных роли с разными уровнями доступа
Кастомные роли с произвольным набором скоупов
API-ключи наследуют роль создателя с возможностью сужения скоупов
Мультиорганизационная изоляция ресурсов
Интеграция с SAML-группами для автоматического маппинга ролей
Политики могут ссылаться на роли для условных действий

Роли

FlowLink поставляется с тремя встроенными ролями, покрывающими большинство сценариев. Встроенные роли нельзя удалить, но можно использовать как основу для кастомных.

adminПолный доступ

Управление пользователями: создание, удаление, смена ролей
Полный доступ к биллингу и подпискам
Создание, изменение и удаление любых политик
Управление агентами, секретами, вебхуками
Доступ к forensic-данным и audit log
Управление кастомными ролями и организациями

operatorОперационный доступ

Управление агентами: регистрация, конфигурация, перезапуск
Создание и редактирование политик безопасности
Просмотр audit log и командной истории
Выполнение команд на агентах
Доступ к метрикам и дашбордам
✗ Нет доступа к биллингу и управлению пользователями

viewerТолько чтение

Просмотр дашборда и метрик
Просмотр списка агентов и их статуса
Просмотр audit log и отчётов
Чтение политик (без редактирования)
✗ Нет доступа к выполнению команд
✗ Нет доступа к секретам и биллингу

Кастомные роли

Для реализации принципа наименьших привилегий вы можете создавать кастомные роли с произвольным набором разрешений. Кастомные роли создаются через API и наследуют поведение встроенных — они проверяются при каждом запросе через тот же механизм скоупов.

bash

1curl -X POST https://relay.example.com/api/v1/roles \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "name": "dev-readonly",
6    "display_name": "Developer Read-Only",
7    "description": "Read-only access for CI/CD and developers",
8    "permissions": {
9      "agents": "read",
10      "policies": "read",
11      "audit": "read",
12      "secrets": "none",
13      "billing": "none",
14      "admin": "none"
15    }
16  }'

Уровни разрешений

Каждый ресурс в permissions может принимать следующие значения:

none

Полный запрет

read

Только чтение

write

Чтение и запись

Пример: CI/CD роль

bash

1curl -X POST https://relay.example.com/api/v1/roles \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "name": "ci-cd-pipeline",
6    "display_name": "CI/CD Pipeline Bot",
7    "description": "Minimal permissions for automated pipelines",
8    "permissions": {
9      "agents": "read",
10      "policies": "read",
11      "audit": "none",
12      "secrets": "none",
13      "billing": "none",
14      "admin": "none"
15    }
16  }'

Ограничение на количество кастомных ролей зависит от тарифа: Team — 10, Business — 50, Enterprise — безлимит.

Scopes (разрешения)

Scopes — это гранулярные разрешения, которые определяют конкретные действия над ресурсами. Каждая роль раскрывается в набор скоупов при авторизации. Встроенная функция can_call("scope") используется в каждом handler'е для проверки доступа.

Агенты и команды

agents:readПросмотр списка агентов и статуса

agents:writeРегистрация, конфигурация, удаление агентов

commands:executeОтправка команд агентам

Политики и аудит

policies:readЧтение политик безопасности

policies:writeСоздание и изменение политик

audit:readПросмотр audit log

Секреты и форензика

secrets:readДоступ к хранилищу секретов

secrets:writeСоздание и ротация секретов

forensics:readПросмотр forensic-отчётов

Биллинг и администрирование

billing:readПросмотр подписки и usage

billing:writeИзменение плана и оплаты

adminПолный административный доступ

Скоупы встроенных ролей

Scope	admin	operator	viewer
agents:read	✅	✅	✅
agents:write	✅	✅	—
commands:execute	✅	✅	—
policies:read	✅	✅	✅
policies:write	✅	✅	—
audit:read	✅	✅	✅
secrets:read	✅	✅	—
secrets:write	✅	—	—
forensics:read	✅	—	—
billing:read	✅	—	—
billing:write	✅	—	—
admin	✅	—	—

API-ключи и RBAC

API-ключи наследуют роль пользователя, который их создал. При этом ключу можно назначить суженный набор скоупов — это полезно для интеграций и CI/CD, которым не нужен полный доступ роли создателя.

Создание ключа с ролью

bash

1# Создать API-ключ с конкретной ролью
2curl -X POST https://relay.example.com/api/v1/keys \
3  -H "Authorization: Bearer $TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "name": "ci-bot",
7    "role": "dev-readonly",
8    "scopes": ["agents:read", "audit:read"]
9  }'

Сужение скоупов ключа

bash

1# Обновить скоупы существующего ключа (можно только сузить)
2curl -X PATCH https://relay.example.com/api/v1/keys/${KEY_ID} \
3  -H "Authorization: Bearer $TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "scopes": ["agents:read"]
7  }'

⚠ Важно

Нельзя назначить API-ключу скоупы, которых нет у роли создателя. Например, operator не может создать ключ с billing:read. Это предотвращает privilege escalation.

Организации

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

Изоляция ресурсов

Агенты одной организации не видны из другой
Политики и audit log изолированы внутри организации
Секреты хранятся в контексте организации
Роли назначаются внутри организации (один пользователь — разные роли)

Организация в JWT

json

1{
2  "sub": "user_abc123",
3  "org_id": "org_xyz789",
4  "role": "operator",
5  "scopes": ["agents:read", "agents:write", "policies:read", "audit:read"]
6}

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

API

Полный API для управления ролями и пользователями. Все эндпоинты требуют авторизации и соответствующих скоупов.

GET /api/v1/roles

Получить список всех ролей организации

bash

1curl https://relay.example.com/api/v1/roles \
2  -H "Authorization: Bearer $TOKEN"

json

1{
2  "roles": [
3    {
4      "id": "role_admin",
5      "name": "admin",
6      "display_name": "Administrator",
7      "builtin": true,
8      "permissions": {
9        "agents": "write",
10        "policies": "write",
11        "audit": "read",
12        "secrets": "write",
13        "billing": "write",
14        "admin": "write"
15      }
16    },
17    {
18      "id": "role_custom_01",
19      "name": "dev-readonly",
20      "display_name": "Developer Read-Only",
21      "builtin": false,
22      "permissions": {
23        "agents": "read",
24        "policies": "read",
25        "audit": "read",
26        "secrets": "none",
27        "billing": "none",
28        "admin": "none"
29      }
30    }
31  ]
32}

POST /api/v1/roles

Создать кастомную роль

bash

1curl -X POST https://relay.example.com/api/v1/roles \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "name": "security-analyst",
6    "display_name": "Security Analyst",
7    "description": "Read access to policies and forensics",
8    "permissions": {
9      "agents": "read",
10      "policies": "read",
11      "audit": "read",
12      "secrets": "none",
13      "billing": "none",
14      "admin": "none"
15    }
16  }'

PUT /api/v1/roles/{id}

Обновить кастомную роль

bash

1curl -X PUT https://relay.example.com/api/v1/roles/role_custom_01 \
2  -H "Authorization: Bearer $TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "display_name": "Developer Read-Only (updated)",
6    "permissions": {
7      "agents": "read",
8      "policies": "read",
9      "audit": "read",
10      "secrets": "read",
11      "billing": "none",
12      "admin": "none"
13    }
14  }'

GET /api/v1/users/me

Получить текущего пользователя с ролью и скоупами

bash

1curl https://relay.example.com/api/v1/users/me \
2  -H "Authorization: Bearer $TOKEN"

json

1{
2  "id": "user_abc123",
3  "email": "alice@example.com",
4  "org_id": "org_xyz789",
5  "role": "operator",
6  "scopes": [
7    "agents:read",
8    "agents:write",
9    "policies:read",
10    "policies:write",
11    "audit:read",
12    "commands:execute"
13  ],
14  "created_at": "2025-06-15T10:30:00Z"
15}

Политики с RBAC

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

json

1{
2  "id": "policy_role_block",
3  "name": "Block commands for viewers",
4  "match": {
5    "user_role": "viewer"
6  },
7  "action": "block",
8  "reason": "Viewers cannot execute commands on agents"
9}

Примеры политик с ролями

json

1{
2  "name": "Require approval for operators",
3  "match": {
4    "user_role": "operator",
5    "command_risk": "high"
6  },
7  "action": "approve",
8  "reason": "High-risk commands from operators require admin approval"
9}

json

1{
2  "name": "Audit-only for viewers",
3  "match": {
4    "user_role": "viewer",
5    "resource": "agents"
6  },
7  "action": "allow",
8  "scope": "read",
9  "reason": "Viewers have read-only access to agents"
10}

Порядок проверки

JWT middleware извлекает роль и скоупы
RBAC проверяет can_call(scope) → 403 если нет
Policy engine проверяет правила с match.user_role
Если политика блокирует → 403 с reason
Если политика требует одобрения → отправка на approval

SAML Group Mapping

При использовании SSO/SAML вы можете автоматически маппить группы из IdP (Identity Provider) на роли FlowLink. Это позволяет централизованно управлять доступом — когда сотрудник добавляется в группу «security-team» в Okta/Azure AD, он автоматически получает роль operator в FlowLink.

json

1{
2  "saml_group_mapping": {
3    "flowlink-admins": "admin",
4    "security-team": "operator",
5    "engineering": "operator",
6    "interns": "viewer",
7    "auditors": "viewer"
8  }
9}

bash

1# Настроить маппинг групп через API
2curl -X PUT https://relay.example.com/api/v1/orgs/${ORG_ID}/sso/group-mapping \
3  -H "Authorization: Bearer $TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "mappings": {
7      "flowlink-admins": "admin",
8      "security-team": "operator",
9      "engineering": "operator",
10      "auditors": "viewer"
11    }
12  }'

Приоритет

Если пользователь состоит в нескольких группах, применяется роль с наибольшими привилегиями (admin > operator > viewer). Если роль назначена вручную через API, она имеет приоритет над SAML-маппингом.

📖 Подробнее о настройке SSO/SAML читайте в разделе SSO / SAML.

Secrets Approval Workflow

Canary Tokens

Соответствие

Edit this page