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

Обзор

Система реализует комплексную модель RBAC для управления контролем доступа к различным ресурсам и действиям. Она состоит из ролей, политик и назначений ролей пользователям.

Основные компоненты

Ресурсы

Система определяет следующие защищённые ресурсы:

• Audit
• DevPod
• Image
• Payment
• Pubkey
• Registry
• Region
• Resource
• Serverless
• Storage
• Team
• Role
• UserRole

Действия

Доступные действия над ресурсами:

• List
• Get
• Create
• Update
• Delete

Система ролей

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

Предопределённые роли

1. AccountAdmin

   • Полный доступ к ресурсам уровня аккаунта
   • Может управлять участниками команды
   • Может настраивать параметры аккаунта

2. Developer

   • Может управлять DevPods
   • Может управлять ресурсами Serverless
   • Может управлять Images
   • Может управлять Storage (только создание/чтение)

3. Auditor

   • Доступ только для чтения к логам Audit

4. Finance

   • Полный доступ к функциям Payment

5. Ops

   • Доступ на чтение к DevPods и Serverless
   • Полный доступ к Images, Storage, Pubkey и Resources

Политики

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

Структура политики

• Resource: Целевой ресурс
• Action: Разрешённое действие

Назначение политик

• Политики назначаются ролям через маппинг RolePolicy
• Несколько политик могут быть назначены одной роли
• Назначения политик уникальны для каждой роли

Контроль прав пользователей

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

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

1. Назначение пользователю

   • Пользователям назначается одна или несколько ролей
   • Назначения ролей специфичны для каждого аккаунта
   • Пользователь может иметь разные роли в разных аккаунтах

2. Роль как мост

   • Роли служат контейнерами для наборов политик
   • Каждая роль определяет конкретный набор обязанностей
   • Роли делают управление правами более удобным

3. Применение политик

   • Политики определяют фактические разрешения
   • Каждый запрос валидируется относительно политик ролей пользователя
   • Доступ предоставляется только при наличии соответствующей политики

Процесс авторизации

1. Обработка запроса

   • Извлечение информации об аккаунте
   • Идентификация целевого ресурса и действия
   • Проверка ролей и политик пользователя

2. Проверка разрешений

   • Роли, специфичные для аккаунта, валидируются относительно целевого аккаунта
   • Сопоставление политик учитывает как точные совпадения, так и wildcards

3. Контроль доступа

   • Доступ предоставляется, если любая назначенная роль имеет соответствующую политику
   • Отклонённые запросы возвращают пустые результаты, а не ошибки
   • Логирование аудита происходит после валидации RBAC

Лучшие практики

1. Управление ролями

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

2. Соображения безопасности

   • Всегда валидируйте контекст аккаунта
   • Реализуйте ограничения UI на основе ролей
   • Ведите логи аудита для изменений ролей

3. Производительность

   • Назначения ролей и политик кэшируются
   • Пакетные операции доступны для массовых назначений
   • Оптимизированные запросы к базе данных для проверки разрешений