HashiCorp Vault больше недоступен: чем российские DevOps-команды управляют секретами в 2026 году
В августе 2023 года HashiCorp сменил лицензию с открытой MPL 2.0 на проприетарную Business Source License. Одновременно компания прекратила сотрудничество с российскими организациями. Через несколько месяцев IBM поглотила HashiCorp за 6,4 млрд долларов, включив Vault в свой корпоративный портфель.
Для российских DevOps-команд это означало одно: использовать актуальные версии Vault бесплатно больше нельзя, а купить лицензию невозможно. С 2023 года Vault практически невозможно использовать в российских компаниях с сохранением лицензионной чистоты из-за новых политик лицензирования.
Прошло больше двух лет. Рынок перестроился, появились альтернативы, команды нашли рабочие подходы. В этой статье разбираем что происходит с управлением секретами в российском DevOps прямо сейчас и какие варианты реально работают.
Почему это важно: что такое управление секретами и где оно нужно
Секрет в контексте DevOps — это любые учётные данные, которые приложение использует для доступа к другим системам. Пароли баз данных, API-ключи, SSH-ключи, токены сервисных аккаунтов, сертификаты, строки подключения.
Проблема простая: эти данные нужно где-то хранить, и при этом они не должны попасть в репозиторий, в логи, на экран разработчика во время демонстрации коллегам. По статистике, более 80% нарушений безопасности связано с компрометацией привилегированных учётных записей.
Vault решал эту задачу для миллионов команд по всему миру: централизованное хранилище с гранулярными политиками доступа, динамическая генерация учётных данных, PKI-инфраструктура, интеграции с Kubernetes, Terraform, CI/CD системами. Это был настоящий стандарт индустрии.
Теперь его нет в доступном формате. Что вместо него?
Ландшафт 2026: три пути которыми пошли команды
Путь первый. Остаться на Community Edition и надеяться
Самый распространённый в первые годы. Community Edition Vault работает по BSL-лицензии — её можно использовать бесплатно при условии что вы не создаёте конкурирующий продукт. Многие команды интерпретировали это широко и продолжили использовать Vault как прежде.
Риск очевиден: нет обновлений безопасности от вендора, нет поддержки, непонятный правовой статус при аудитах. Для крупных регулируемых организаций — финансовый сектор, госструктуры, КИИ — этот путь неприемлем.
Путь второй. Перейти на российские форки и аналоги
Рынок отреагировал на запрос довольно быстро. Сегодня в России есть несколько продуктов, претендующих на роль замены Vault.
Deckhouse Stronghold от той же команды что делает платформу Deckhouse. В его основе форк HashiCorp Vault CE версии 1.14.8, последнего коммита под лицензией MPL. Разработчики существенно расширили функциональность исходного продукта и позиционируют его как переосмысление идеального хранилища секретов для российского бизнеса. Для команд уже знакомых с Vault миграция относительно безболезненна — API совместимы. 4PDA
StarVault от Orion soft. Orion soft выпустила решение для безопасного хранения и доступа к конфиденциальной информации и называет его полноценным аналогом HashiCorp Vault с вендорской поддержкой. По словам вендора, в большинстве случаев замена HashiCorp Vault осуществляется по одной из трёх причин: реализация политики импортозамещения, необходимость соблюдения лицензионной чистоты или отсутствие возможности использовать продукт из-за его недоступности на российском рынке.
Оба решения покрывают сценарии сложной инфраструктуры: динамические секреты, PKI, ротация учётных данных баз данных. Но оба требуют серьёзных инвестиций во внедрение и эксплуатацию.
Путь третий. Переосмыслить задачу
Это самый интересный путь. Vault всегда был сложным инструментом. Он решал задачи enterprise-уровня и требовал соответствующих инвестиций: инженеры с сертификацией HashiCorp, отдельная команда для эксплуатации кластера, месяцы внедрения.
Реальность большинства российских DevOps-команд другая. Им не нужна динамическая генерация учётных данных для 200 баз данных. Им нужно решить конкретную задачу: как безопасно передать секреты в CI/CD пайплайн без хранения в репозитории и переменных окружения платформы.
Для этого сценария полноценный аналог Vault избыточен. Корпоративный менеджер паролей с документированным API закрывает большинство практических задач за несравнимо меньшие деньги и усилия.
Что реально нужно большинству команд: честная декомпозиция задачи
Vault умел много. Но если спросить DevOps-инженеров что они реально использовали каждый день, ответы сведутся к нескольким сценариям.
Сценарий 1. Передача секретов в CI/CD пайплайн. Пайплайн при запуске должен получить пароль от базы данных, API-ключ внешнего сервиса, токен для деплоя. Хранить это в репозитории нельзя. Хранить в переменных окружения платформы можно, но тогда нет нормального аудита и ротации.
Сценарий 2. Хранение инфраструктурных секретов. SSH-ключи для подключения к серверам, учётные данные сервисных аккаунтов, строки подключения. Нужно хранить централизованно, выдавать нужным людям и системам, знать кто и когда обращался.
Сценарий 3. Управление секретами в Kubernetes. Приложения в кластере должны получать секреты при старте. Native Kubernetes Secrets — это base64 в etcd без нормального шифрования at rest, без аудита, без ротации.
Сценарий 4. Разграничение доступа разных команд. Разработчики видят секреты своего сервиса и не видят секреты соседней команды. Подрядчики получают временный доступ к конкретным ресурсам.
Vault закрывал всё это и ещё много дополнительных сценариев — динамические секреты, PKI, шифрование как сервис. Для большинства команд дополнительные сценарии были лишней сложностью которую они не использовали, но за которую платили временем инженеров и ресурсами на эксплуатацию.
Как BearPass закрывает практические задачи DevOps
BearPass изначально разрабатывался как корпоративный менеджер паролей для команд. В версии 2.25.0 появилась аутентификация через JWT от внешних OpenID Connect провайдеров — именно то что нужно для интеграции в автоматизированные пайплайны.
Получение секретов в CI/CD через REST API
Схема работает так. Пайплайн при запуске запрашивает временный JWT-токен у OpenID Connect провайдера (Keycloak, Мультифактор или любой другой IdP). Этим токеном он аутентифицируется в BearPass API и получает нужные секреты в формате JSON. Секрет используется в текущей сессии и нигде не сохраняется.
Вот как это выглядит на практике в GitLab CI:
В репозитории нет ни одного реального секрета — только BEARPASS_URL. Токен GitLab CI OIDC выдаётся автоматически платформой для каждого запуска и действителен только во время этого запуска. В BearPass создаётся сервисная учётная запись с доступом только к папке Production — и больше ни к чему.
Получение секретов через CLI в скриптах деплоя
Для shell-скриптов удобнее использовать BearPass CLI напрямую:
Разграничение доступа для разных команд через Пространства
В BearPass 2.26.0 появился модуль Пространства — изоляция данных по командам или проектам внутри одной установки. Команда backend видит только секреты своих сервисов. Команда frontend работает со своим набором. Подрядчик на проекте получает временный доступ к папке конкретного проекта.
Это закрывает сценарий разграничения доступа без развёртывания нескольких экземпляров системы и без сложной политики Vault.
Сравнение подходов: что выбрать
Честное сравнение для разных ситуаций:
Типичные сценарии и что выбрать
У вас было Vault и нужна замена с сохранением архитектуры
Если инфраструктура уже построена вокруг Vault — политики HCL, интеграции через Vault Agent, динамические учётные данные для баз данных — логичнее всего смотреть на Deckhouse Stronghold. API совместимо с Vault CE, миграция относительно безболезненна, лицензионная чистота обеспечена.
Для крупных инфраструктур со сложными требованиями к PKI и динамическим секретам стоит изучить StarVault.
Вам нужно убрать секреты из репозиториев и переменных окружения CI/CD
Это самый частый практический запрос. Хочется чтобы DB_PASSWORD не жила в GitLab CI Variables и не светилась в логах. При этом никто не хочет разворачивать полноценный Vault-кластер ради этого.
BearPass с REST API закрывает эту задачу прямо. Пайплайн получает секрет через API, использует его в сессии — и всё. В конфигурации CI только адрес сервера BearPass и JWT-токен от IdP. Сам секрет нигде не хранится.
Нужно управлять доступами к секретам для разных команд
Команда backend не должна видеть секреты фронтенда. Подрядчик на проекте получает доступ только к нужным ресурсам. Уволенный сотрудник теряет всё мгновенно.
Это задача управления доступами, не секрет-менеджмента в классическом смысле. RBAC с папками и группами в BearPass закрывает её полностью — с журналом событий, Kill Switch и автоматическим отзывом через LDAP.
Вы на КИИ или в регулируемой отрасли
Здесь нужен продукт из Реестра Минцифры. BearPass включён под номером 15427, StarVault находится в процессе сертификации ФСТЭК. Vault CE в этом контексте неприемлем.
Что не стоит делать
Продолжать использовать актуальный Vault CE в продакшне без анализа рисков. BSL-лицензия содержит ограничения, и при аудите — особенно в регулируемых отраслях — это может стать проблемой. Как минимум стоит получить юридическую оценку.
Хранить секреты в переменных окружения CI/CD платформы. GitHub Secrets, GitLab CI Variables, Bitbucket Secured Variables решают задачу частично: нет нормального аудита, нет ротации, нет гранулярного RBAC. При компрометации аккаунта платформы секреты уходят вместе.
Класть секреты в .env-файлы в репозитории. Это всё ещё встречается. Даже в приватных репозиториях — потому что доступ к репозиторию имеет много людей, а история коммитов хранит данные вечно.
Запускать Vault без нормальной операционной команды. Vault сложен в эксплуатации. Его нужно unsealing при рестарте, мониторить, бэкапить. Команда которая развернула Vault «по туториалу» и забыла — это не безопасность, это иллюзия безопасности.
Практический вывод
Рынок управления секретами в России перестраивается. Полноценные замены Vault появились и продолжают развиваться — Deckhouse Stronghold и StarVault покрывают сложные enterprise-сценарии.
Для большинства команд которым не нужны динамические секреты и PKI прагматичный путь выглядит иначе: корпоративный менеджер паролей с REST API закрывает 80% практических задач за несравнимо меньший операционный overhead. Секреты в пайплайне через API, разграничение доступа через RBAC, журнал всех обращений — этого достаточно для большинства сценариев.
Vault был хорош тем что умел много. Хорошая замена — это не обязательно продукт который умеет столько же. Это продукт который умеет именно то что нужно вашей конкретной команде прямо сейчас.