Deckhouse Platform и система управления секретами Deckhouse Stronghold подтвердили совместимость с «Ред АДМ» промышленной редакции. Для компаний, которые строят Kubernetes-инфраструктуру на российском ПО, связка Deckhouse и Ред АДМ означает более приземлённую вещь, чем красивый лозунг про «единый пульт»: учётные записи и права сотрудников можно не размножать по нескольким системам. Об итогах испытаний сообщает CNews.
Проверка охватила работу продуктов «Фланта» с системой централизованного управления ИТ-инфраструктурой от «Ред Софт» на базе «Ред ОС 8». В тестовом стенде «Ред АДМ» использовался как корпоративный каталог пользователей, а Deckhouse Platform и Stronghold получали из него данные для аутентификации и назначения полномочий. Вендоры заявляют, что интеграция работает стабильно как для платформы контейнеризации, так и для управления секретами.
Права не нужно поддерживать вручную в каждой системе
Практическая ценность совместимости — в отказе от параллельного ведения пользователей. В типичной инфраструктуре у администратора есть доменный каталог, кластер Kubernetes, интерфейсы платформы, хранилища секретов и отдельные сервисные контуры. Если доступы выдаются в каждом из них вручную, увольнение разработчика или перевод инженера превращается в набор заявок и чек-листов. Один забытый аккаунт — уже не бюрократическая мелочь, а потенциальный путь в продакшен.
В испытаниях связку «Ред АДМ» и Deckhouse Platform настроили через защищённый протокол LDAPS и провайдер Dex. Dex в этой схеме выступает посредником между каталогом пользователей и приложениями, которые используют современные механизмы аутентификации. Пользователь входит с корпоративной учётной записью, а платформа получает информацию о его группах и на её основе принимает решение о доступе. Это привычная для корпоративной инфраструктуры логика, но её наличие в подтверждённой связке особенно важно там, где заказчик ограничен перечнем совместимого российского ПО.
Отдельно проверили ролевую модель доступа RBAC. Она позволяет связать права с членством в группах каталога: например, дать команде разработки доступ только к своему пространству имён Kubernetes, а инженерам эксплуатации — более широкие полномочия. В пределах кластера это помогает разделять среды и команды без раздачи избыточных прав. Не каждый разработчик должен видеть секреты соседнего сервиса, а не каждый администратор — иметь возможность менять настройки всего кластера.
Для Deckhouse Stronghold, который отвечает за работу с секретами, подтверждены два сценария: использование внутри кластера и изолированная установка. В обоих случаях продукт корректно применял политики из корпоративного каталога. Речь идёт о доступе к таким чувствительным объектам, как пароли, сертификаты и ключи шифрования. Именно здесь ручная выдача и отзыв прав особенно опасны: забытый допуск может пережить и смену должности, и уход сотрудника.
Совместимость как часть импортонезависимого контура
Стенд развернули в среде виртуализации Deckhouse Platform, а гостевой ОС стала сертифицированная ФСТЭК России «Ред ОС 8». Для заказчиков из регулируемых отраслей это не декоративная деталь. Им мало заменить один продукт: нужно собрать рабочую цепочку из операционной системы, виртуализации, платформы контейнеризации, каталога пользователей и средств защиты. Любое неподтверждённое звено заставляет проводить собственные испытания, оформлять исключения или оставлять прежний продукт там, где его уже хотелось бы заменить.
Анна Авхимович, руководитель направления маркетинга технологических партнёров «Ред Софт», описала результат как объединение классической доменной архитектуры с Kubernetes-средой. Формулировка точная: корпоративный каталог обычно появился раньше контейнерной платформы и продолжает быть источником истины о сотрудниках, группах и базовых правилах доступа. Интеграция не заставляет службу эксплуатации изобретать новый контур идентификации только ради кластеров.
Директор продуктового направления «Фланта» Карапет Манасян связывает проект с подходом Zero Trust. В данном случае это не означает, что платформа магически решает все задачи защиты. Смысл скромнее и полезнее: права пользователя должны следовать за его актуальной ролью в организации, а не храниться в наборе локальных аккаунтов. Если сотрудника переводят в другую команду или увольняют, изменение групп в «Ред АДМ» должно отразиться в доступах к кластерам и секретам без ручной ревизии каждой панели управления.
Для разработчиков это может означать более предсказуемый онбординг и меньше ожидания доступов: команда получает нужные роли через корпоративные группы, а не через разрозненные учётные записи. Для ИТ-директора — меньше операционной рутины и проще аудит того, кто имеет доступ к конкретному контуру. Для службы информационной безопасности — возможность строить контроль вокруг одного каталога, а не собирать данные из нескольких систем постфактум.
При этом подтверждённая технологическая совместимость не отменяет проектную работу. Заказчику всё равно придётся продумать структуру групп, границы пространств имён, правила выдачи привилегированных ролей и процесс отзыва доступов. Но Deckhouse и Ред АДМ снимают один из частых барьеров: необходимость самостоятельно доказывать, что каталог, Kubernetes-платформа и менеджер секретов вообще смогут работать вместе. Следующий важный вопрос для рынка — насколько быстро такие готовые связки станут стандартом не только в пилотах, но и в крупных распределённых инфраструктурах.
