Цель и назначение системы

Deckhouse Development Platform (DDP) — это IDP (Internal Developer Platform), внутренняя платформа разработки, которая объединяет в себе инструменты, инфраструктурные сервисы и процессы разработки.

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

Основные задачи платформы:

  • Обеспечение единых стандартов разработки для команд через шаблоны и типовые конфигурации.
  • Управление динамическими окружениями с автоматическим созданием, обновлением и удалением сред.
  • Интеграция с внешними инфраструктурными сервисами через API.
  • Упрощённый онбординг разработчиков и команд за счёт шаблонных решений и документации.
  • Оцифровка процессов и сценариев разработки через BPMN-подобный механизм описания процессов.
  • Встроенная CMDB для автоматического сбора данных из инфраструктурных сервисов и визуализации зависимостей.
  • Контроль параметров сущностей через механизм проверок статуса.

Пользователи системы

Команды разработки

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

Менеджмент

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

Команды инфраструктуры и платформенные команды

Эти команды отвечают за предоставление сервисов и ресурсов через DDP. Они настраивают интеграции с внешними сервисами, конфигурируют ресурсы, создают шаблоны и автоматизации, управляют окружениями и обеспечивают работу платформы.

Команды безопасности

Команды безопасности используют DDP для предоставления и управления средствами защиты, проведения аудита и контроля соблюдения требований. В рамках платформы они настраивают политики безопасности и права доступа, просматривают аудит-логи и управляют механизмами защиты.

Администраторы

Администраторы — пользователи, обладающие полными правами на настройку и сопровождение платформы. Они управляют учетными записями пользователей, настраивают роли и права доступа через систему RBAC, конфигурируют интеграции с внешними сервисами, управляют учетными данными, ресурсами, автоматизациями и параметрами платформы, а также просматривают аудит-логи.

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

Доступ к системе

Веб-интерфейс

Все группы пользователей получают доступ к платформе через веб-интерфейс DDP Frontend, предназначенный для работы с платформой в веб-браузере.

Протокол доступа: HTTPS (TCP/443)

Аутентификация: Пользователи проходят аутентификацию через компонент Dex, который интегрируется с внешними провайдерами аутентификации (Keycloak, LDAP и др.) через стандартные протоколы (OIDC, LDAP). После успешной аутентификации пользователь получает JWT токен доступа, который используется для авторизации запросов к платформе.

REST API

Администраторы и разработчики могут напрямую обращаться к DDP Backend через REST API для программного взаимодействия с платформой.

Протокол доступа: HTTPS (TCP/443)

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

  • Браузер: сессия по httpOnly cookie (JWT от Dex).
  • Программный доступ: API-токен из раздела «Профиль», заголовок Authorization: Bearer <api_token>.

REST API предоставляет полный набор функций для управления всеми объектами платформы: сущностями, ресурсами, действиями, источниками данных, виджетами, процессами и другими компонентами.

Доступ снаружи/внутри периметра компании

Платформа DDP развертывается в кластере Kubernetes и может быть доступна как внутри корпоративного периметра, так и снаружи, в зависимости от конфигурации сетевой инфраструктуры.

Доступ внутри периметра

Типичный сценарий: Пользователи получают доступ к платформе через внутреннюю сеть компании.

  • Веб-интерфейс и REST API доступны через внутренний Ingress-контроллер.
  • Доступ осуществляется по внутренним доменным именам (например, ddp.internal.company.com).
  • Аутентификация может быть интегрирована с корпоративным LDAP или Active Directory через Dex.
  • Дополнительная защита может обеспечиваться на уровне сетевых политик Kubernetes.

Доступ снаружи периметра

Типичный сценарий: Пользователи получают доступ к платформе извне корпоративной сети.

  • Веб-интерфейс и REST API доступны через публичный Ingress-контроллер.
  • Доступ осуществляется по публичным доменным именам (например, ddp.company.com).
  • Аутентификация может быть интегрирована с внешними провайдерами аутентификации через Dex.

Гибридный доступ

Платформа может быть настроена для поддержки обоих сценариев одновременно:

  • Внутренние пользователи получают доступ через внутренний Ingress.
  • Внешние пользователи (например, удаленные сотрудники) получают доступ через публичный Ingress или VPN.
  • Различные группы пользователей могут использовать разные провайдеры аутентификации через Dex.

Конфигурация доступа настраивается администратором при развёртывании платформы через параметры Ingress-контроллера и сетевые политики Kubernetes.