Общие сведения о программном коплексе Salt.Box

Назначение

Программный комплекс Salt.Box предназначен для управления программными конфигурациями рабочих станций с целью обеспечения их функционирования в требуемом согласованном состоянии, развёртывания системного и прикладного программного обеспечения на рабочих станциях, мониторинга состояния рабочих станций.

Область применения

• Инвентаризация аппаратного и программного обеспечения автоматизированных рабочих мест пользователей
• Управление программными конфигурациями рабочих станций в гибридной информационно-технологической инфраструктуре
• Управление групповыми политиками
• Перевод рабочих станций на использование ОС семейства GNU/Linux и Linux-совместимого прикладного программного обеспечения
• Конфигурирование прикладного программного обеспечения

Основные функциональные возможности

• Многопользовательский режим работы c управлением доступом на основе ролей
• Получение подробной информации о парке вычислительной техники предприятия, статистической информации об аппаратном и программном обеспечении рабочих станций
• Развитые средства фильтрации и группировки рабочих станций на основе их аппаратных и программных характеристик, состояния программной конфигурации, различных отслеживаемых параметров
• Асинхронное параллельное выполнение задач управления программными конфигурациями на отдельных физических или виртуальных машинах или на группах машин
• Событийно-управляемый запуск сценариев управления программными конфигурациями рабочих станций
• Единый веб-интерфейс управления рабочими станциями, задачами и шаблонами задач, сценариями управления и отчётами
• Интеграционная шина для подключения модулей, расширяющих функциональность программного комплекса

Архитектура программного комплекса Salt.Box

Рисунок 1. Архитектура программного комплекса Salt.Box

Таблица 1. Взаимодействия компонентов, контейнеров и подсистем программного комплекса Salt.Box

№	Описание
1	Взаимодействие пользователя с веб-приложением по протоколу http или https
2	Веб-приложение работает с API-шлюзом через обратный прокси
3	Для выполнения процедуры аутентификации логин и пароль пользователя передаются системе KeyCloak
4	KeyCloak использует СУБД PostgreSQL для хранения регистрационных данных пользователя и хеша его пароля
5	Интеграция KeyCloak с корпоративным каталогом LDAP позволяет использовать существующие учетные записи пользователей. Использование OpenID Connect обеспечивает единый вход для всех подключённых приложений
7	KeyCloak выдаёт JSON Web Token (JWT) для доступа веб-приложения к компонентам Salt.Box
8	Передача JWT в составе любого запроса, совершаемого веб-приложением
9	API-шлюз выполняет валидацию JWT, полученного в составе любого запроса, в стистеме KeyCloak
10	Если JWT валиден, API-шлюз запрашивает у OPA (Open Policy Agent) политику доступа пользователя-владельца токена к Salt.Box
11	Проверка обновлений, получение, упаковка и сохранение изменений в бандлах (bundles)
12	Если политика доступа разрешает пользователю выполнение запроса, API-шлюз транслирует запрос компоненту Core — интерфейсу ядра программного комплекса Salt.Box
13	Сервис Core сохраняет временные данные (данные pillars, команды, результаты выполнения команд), в Redis store — хранилище ключ-значение на базе Redis
14	«Движки» (engines) Salt Master-сервера также имеет доступ к хранилищу Redis store, получают из него и сохранят результаты выполнения — Job Return — и прочие структуры данных. Результаты выполнения задач сохраняются с заданным временем жизни (TTL)
15, 16	Сервис Core осуществляет синхронные вызовы (RPC) и обработку событий (Events) через брокер сообщений на базе Redis Pub/Sub channels, управляемый фреймворком FastStream
17	Статические данные (коллекции, параметры миньонов и мастер-серверов, схемы команд, шаблоны задач, настройки Salt.Box) хранятся в БД под управлением MongoDB
18	Сервис Core после обработки запроса и выполнения соответствующих команд на стороне миньонов SaltStack возвращает ответ API-шлюзу
19	API-шлюз транслирует ответ веб-приложению для отображения результата пользователю
20	Сервис Core осуществляет запуск продолжительных асинхронных задач посредством Taskiq, используя RabbitMQ в качестве брокера сообщений. Дополнительно Taskiq предоставляет планировщик для выполнения задач по расписанию
21	Запрос к модулю расширения Salt.Box выполняется по аналогии с п. 12
22	Модуль расширения Salt.Box осуществляет запуск продолжительных асинхронных задач по аналогии с п. 20
23	Модуль расширения Salt.Box после обработки запроса и выполнения соответствующих команд на стороне миньонов SaltStack возвращает ответ API-шлюзу
24	Salt Master публикует задания (Jobs), получает события, созданные миньоном, генерирует собственные события
25	Мииньон получает задания (Jobs), получает события, созданные мастером, генерирует собственные события
26	Получение данных от встроенного в Salt Master файл-сервера
27	Данные, возвращаемые миньоном (Job returns)

Описание процедуры аутентификации

Процедура аутентификации реализована с использованием современных стандартов OAuth 2.0 и OpenID Connect:

1. Фронтенд инициирует процесс аутентификации при открытии веб-приложения

2. Фронтенд формирует URL для перенаправления на сервер KeyCloak со следующими параметрами:

   • client_id - идентификатор клиентского приложения в KeyCloak
   • redirect_uri - URL для возврата после успешной аутентификации
   • response_type - code для flow-авторизации
   • scope - запрашиваемые разрешения (например, openid profile email)
   • state - случайное значение для предотвращения CSRF-атак

3. Пользователь вводит учётные данные на странице KeyCloak

4. При успешной аутентификации сервис KeyCloak:

   • создаёт сессию для пользователя
   • генерирует токены JWT (access и refresh)
   • перенаправляет пользователя обратно на указанный redirect_uri с токенами

5. Фронтенд получает токены JWT и сохраняет их в localStorage

6. Все последующие запросы от фронтенда к API включают JWT access token в заголовок Authorization

7. Когда access token истекает, фронтенд автоматически использует refresh token для получения нового access token без повторной аутентификации пользователя

Рисунок 2. Диаграмма процесса аутентификации пользователя Salt.Box

Аутентификация пользователей KeyCloak через LDAP

Интеграция KeyCloak с корпоративным каталогом LDAP позволяет использовать существующие учетные записи пользователей.
Для настройки интеграции администратор KeyCloak выполняет следующие действия:

1. Создает новый User Federation Provider типа LDAP в консоли администратора

2. Настраивает параметры подключения:

   • Connection URL — адрес LDAP-сервера (например, ldap://ldap.example.com:389)
   • Bind DN и Bind Credential — учётные данные для подключения к LDAP
   • Users DN — база для поиска пользователей (Base DN)
   • Connection Pooling — включение пула соединений для производительности

3. Настраивает стратегию синхронизации:

   • Edit Mode — режим редактирования (READ_ONLY, WRITABLE, UNSYNCED)
   • Sync Registrations — синхронизация новых регистраций
   • Batch Size — размер пакета при синхронизации большого числа пользователей

4. Определяет сопоставление (mapping):

   • Атрибутов Username, Email, First Name, Last Name и пр. атрибутам в KeyCloak
   • групп LDAP группам в KeyCloak

5. Запускает первичную синхронизацию для импорта существующих пользователей.
   Далее система автоматически аутентифицирует пользователей через LDAP при их входе в KeyCloak

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

Open Policy Agent (OPA) и распространение политик

OPA — это инструмент для определения и применения единых политик безопасности в микросервисной архитектуре:

1. Бандлы (bundles) — основной механизм распространения политик OPA:

   • упакованные архивы с политиками, правилами и данными
   • обычно включают файлы в формате Rego (язык политик OPA)
   • могут содержать дополнительные JSON-данные для контекста

2. Жизненный цикл бандла:

   • Создание политик в Rego разработчиками безопасности
   • Упаковка политик в бандл (архив) с помощью CLI или API
   • Публикация бандла в хранилище (HTTP-сервер, S3, Git)
   • Загрузка бандла агентами OPA через настроенные точки дистрибуции

3. Обновление политик:

   • OPA периодически проверяет источник на наличие обновлений
   • OPA загружает новые версии бандлов автоматически
   • OPA применяет изменения без перезапуска сервисов

4. Версионирование:

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