ГЛАВА 2. АНАЛИЗ КОНТЕЙНЕРНЫХ, IaC- И КЛИЕНТСКИХ ПОДХОДОВ К РЕАЛИЗАЦИИ ПЛАТФОРМЫ

В главе проводится сравнительный анализ инструментальных решений в трёх ключевых областях: оркестрация контейнеров, управление инфраструктурой как кодом и проектирование клиентской части. Для каждой области выявлены альтернативы, сформулированы критерии выбора и обоснованы принятые решения.

2.1 Методологическая база исследования

В работе применён инженерно-экспериментальный подход, включающий: архитектурный анализ альтернатив по формализованным критериям; проектирование целевой модели безопасности на основе STRIDE; реализацию прототипа промышленного типа (близкий к промышленному); стендовые испытания по функциональным, нагрузочным и защитным критериям; количественную оценку результатов. Логика исследования соответствует циклу: «требования → архитектурные гипотезы → реализация → измерение → валидация гипотез», что соответствует методологии Design Science Research, применяемой в инженерных диссертационных работах 21.

2.2 Контейнеризация и оркестрация

2.2.1 Обоснование выбора контейнеров

Контейнерная модель выбрана как альтернатива полноценным виртуальным машинам на основании следующих измеримых преимуществ. Накладные расходы по оперативной памяти для контейнера составляет менее 5% от выделенного объёма, тогда как для VM на гипервизоре VMware составляет 15–20% 3. Медианное время старта контейнера (с прогретым кэшем образа) составляет 1–3 секунды, тогда как для VM этот показатель составляет от 30 до 90 секунд. Стандартизированный формат OCI-образов обеспечивает воспроизводимость сборки и совместимость с CI/CD-конвейерами. Нативная интеграция с GitOps-инструментарием снижает долю ручных операций в процессе релиза. Для учебной платформы эти характеристики критически важны: они обеспечивают выполнение НФТ-1 (время старта ≤ 20 с) и НФТ-2 (≥ 30 параллельных сессий).

2.2.2 Сравнительный анализ оркестраторов

Для обоснования выбора Kubernetes как оркестратора проведён сравнительный анализ трёх конкурирующих решений: Kubernetes (K8s), Docker Swarm и HashiCorp Nomad. Таблица 3 содержит сравнение по критериям, существенным для данной задачи.

Таблица 3. Сравнительный анализ оркестраторов контейнеров

Docker Swarm значительно проще в развёртывании, однако не предоставляет нативной поддержки NetworkPolicy на уровне пространства имён, а его RBAC ограничен базовыми ролями. HashiCorp Nomad является технически зрелым продуктом, однако изоляция пространств имён в нём реализуется через плагины и не обеспечивает эквивалентного K8s уровня сетевой сегментации. Kubernetes, несмотря на более высокую операционную сложность, предоставляет полный необходимый стек: NetworkPolicy, стандарты безопасности подов (PodSecurityStandards), детализированный RBAC, богатую экосистему безопасности (OPA/Gatekeeper, Falco, Cosign) и нативную поддержку GitOps-операторов (ArgoCD, Flux). Именно этот набор свойств обеспечивает выполнение НФТ-3 (изоляция) и НФТ-6 (GitOps).

2.3 Infrastructure as Code и GitOps

2.3.1 Сравнение IaC-инструментов

Для управления конфигурацией кластера рассматривались три подхода: Helm, Kustomize и Terraform. Их сравнение по ключевым характеристикам приведено в таблице 4.

Таблица 4. Сравнение IaC-инструментов для управления Kubernetes

Helm выбран как основной инструмент управления прикладными компонентами платформы, поскольку предоставляет встроенный механизм управления версиями релизов (обновление (helm upgrade) и откат (helm rollback)), поддержку зависимостей через Chart.yaml и нативную интеграцию с ArgoCD. Kustomize применяется дополнительно для патчей для каждого окружения (разработка / тестирование / производство). Terraform используется вне уровня K8s, а именно для управления облачными ресурсами и DNS, что соответствует его типовому назначению 17.

2.3.2 GitOps-процесс

GitOps-подход задаёт единый источник истины: фактическое состояние кластера должно совпадать с состоянием, описанным в репозитории Git. Все изменения конфигурации допускаются исключительно через запрос на слияние с обязательным прохождением CI-проверок и ревью. Нарушения согласованности (дрейф конфигурации) автоматически обнаруживаются и устраняются оператором синхронизации. Это обеспечивает трассируемость каждого изменения, возможность быстрого отката к предыдущую стабильную ревизию и снижение влияния человеческого фактора на эксплуатационный процесс.

Схема GitOps-конвейера представлена на рисунке 2.

Рисунок 2. Схема GitOps-конвейера: от коммита до кластера.

2.3.3 Асинхронная очередь инфраструктурных задач

Создание лабораторного Pod - операция с непредсказуемой длительностью (10–60 секунд): необходимо вызвать Kubernetes API, применить манифесты, дождаться перехода Pod в состояние Ready. Синхронный вызов такой операции внутри HTTP-обработчика API привёл бы к timeout клиентских запросов и существенному ограничению параллелизма.

Для разделения ответственности принята асинхронная архитектура на базе Celery и RabbitMQ:

• FastAPI backend публикует задачу (create_lab_pod, delete_lab_pod) в очередь RabbitMQ и немедленно возвращает ответ клиенту со статусом PENDING;
• Celery Workers - отдельный Kubernetes Deployment в namespace platform - получают задачи из очереди, генерируют K8s-манифесты через Jinja2-шаблоны и применяют их через Kubernetes API; после перехода Pod в состояние Ready записывают URL подключения в PostgreSQL;
• Celery Beat (встроенный планировщик задач) каждые 5 минут проверяет записи LabInstance в PostgreSQL и публикует delete_lab_pod для Pod'ов, превысивших TTL (120 минут по умолчанию).

Принципиальное архитектурное ограничение: FastAPI backend не имеет прямого доступа к Kubernetes API. Единственный компонент, авторизованный на операции с K8s-ресурсами, - Celery Workers. Это минимизирует привилегированную поверхность атаки: даже при компрометации публичного API endpoint злоумышленник не получает прямого доступа к Kubernetes control plane.

FastAPI backend  →  RabbitMQ  →  Celery Workers  →  Kubernetes API
  (бизнес-логика)    (очередь)    (инфраструктура)    (выполнение)

2.4 Метод обеспечения безопасности платформы

Безопасность платформы обеспечивается комплексным применением принципов проектирования защищённых систем 13. Принцип минимальных привилегий реализуется через гибридную модель авторизации: на прикладном уровне - комбинацией RBAC (грубозернистые системные роли в Keycloak) и ABAC (ресурсно-ориентированные проверки в backend); на уровне Kubernetes API - через RBAC сервисных аккаунтов (ClusterRole / Role). Принцип нулевого доверия применяется внутри кластера: ни одному пространству имён и ни одному сервисному аккаунту не предоставляется доверие по умолчанию - допускаются только явно разрешённые взаимодействия. Принцип глубокой эшелонированной защиты означает, что каждый слой архитектуры имеет собственные защитные механизмы, независимые от других слоёв.

Цепочка поставки артефактов защищена через статический и уязвимостный анализ образов в CI-конвейере, подпись артефактов с помощью Cosign 9, контроль происхождения образа при развёртывании и запрет деплоя при нарушении политики качества или безопасности. Секреты изолированы от прикладной конфигурации: параметры без чувствительных данных хранятся в ConfigMap, токены, ключи и пароли хранятся в Secret, а доступ сервисов к секретам ограничен сервисными аккаунтами и K8s RBAC 15.

2.5 Подход к проектированию клиентской части

Клиентская часть платформы реализована на базе Nuxt 4 / Vue 3 с TypeScript как Nuxt universal app со слоёной архитектурой (Domain / Application / Infrastructure / App). Применение Nuxt 4 обеспечивает файловую маршрутизацию, Composition API, SSR/CSR-режим и строгую типизацию. Управление состоянием реализовано через встроенный примитив Nuxt useState - реактивный composable с поддержкой SSR-гидратации; внешний стейт-менеджер (Pinia и аналоги) не используется. Валидация входных данных выполняется через библиотеку Zod (schema-first validation). UI-компоненты построены на базе @nuxt/ui - headless UI-библиотеки, интегрированной с Nuxt. TypeScript снижает классы ошибок на этапе разработки посредством статического анализа типов.

Аутентификация реализована как backend-owned OIDC flow через Keycloak 18: браузер направляется на точку входа GET /api/v1/auth/login, backend выполняет перенаправление к Keycloak, а после авторизации пользователя backend самостоятельно выполняет code exchange (PKCE) и возвращает браузеру opaque-сессионную cookie. Клиентская часть не владеет кодовым обменом и не хранит токены доступа. Для определения доступных действий фронт обращается к единственному bootstrap-endpoint GET /api/v1/auth/me, который возвращает массив effective_capabilities - набор явно разрешённых серверной политикой операций.

Навигация и рендеринг интерфейса реализованы по принципу capability-driven UI: маршруты, пункты меню и управляющие элементы отображаются исключительно на основании полученных effective_capabilities. Это снижает операционные ошибки пользователя и уменьшает поверхность атаки интерфейса. Фронт не является механизмом безопасности сам по себе - он лишь отражает решения, принятые серверной гибридной моделью авторизации (RBAC + capability bundles + ABAC). Данный принцип соответствует рекомендациям OWASP Authorization Cheat Sheet 19.

2.6 Метрики и критерии оценки

Для верификации результатов приняты следующие измеримые метрики: время запуска лабораторной среды T_start (секунды); задержка API: p50 и p95 (миллисекунды); доля ошибок API (%); коэффициент изоляции: доля успешных межсессионных соединений (целевое значение 0); утилизация CPU и RAM под нагрузкой (%); доля ручных операций в процессе релиза (%). Доступность сервиса формально оценивается как:

Availability = 1 − (Downtime / ObservationPeriod)

Данный набор метрик обеспечивает проверку как инженерной эффективности, так и безопасности решения, и соответствует стандартным практикам надёжной эксплуатации (SRE) 22.

2.7 Вывод по главе

Результаты сравнительного анализа подтверждают, что устойчивый результат достигается не отдельным инструментом, а согласованной комбинацией: Kubernetes как оркестратор с богатой экосистемой безопасности; Helm как инструмент управления прикладными компонентами; GitOps как процессная модель изменений; принципы проектирования защищённых систем как архитектурная основа. В части инфраструктурной логики ключевым архитектурным решением является асинхронная очередь на базе RabbitMQ и Celery Workers: FastAPI backend публикует задачи в очередь и не имеет прямого доступа к Kubernetes API, тогда как Celery Workers являются единственным компонентом, авторизованным на работу с K8s-ресурсами. Планировщик Celery Beat автоматически управляет жизненным циклом лабораторных Pod'ов по TTL. Клиентский слой реализован на Nuxt 4 / Vue 3 с capability-driven навигацией и backend-owned OIDC-аутентификацией через Keycloak. Эта комбинация положена в основу архитектуры, рассматриваемой в главе 3.