Сравнение · 2 из 5
Wardhold и Yandex Lockbox
Это единственное сравнение, где спорить о доменной модели не о чем: мы её сознательно повторили. Секрет хранит метаданные, значения живут в иммутабельных версиях, секрет активируется и деактивируется, версия уничтожается отложенно, роли делят метаданные и содержимое. Отличия начинаются за пределами модели.
Коротко
Yandex Lockbox — управляемый сервис внутри Yandex Cloud: доступность, обновления и бэкапы — забота провайдера, ключи шифрования берутся из KMS, права раздаёт общий IAM, а счёт складывается из числа версий и числа операций чтения.
Wardhold ведёт себя так же, но живёт там, где нужно вам: в облаке, на своей виртуалке, в закрытом контуре без интернета или на площадке заказчика. Сверх машинных секретов у него есть то, чего у Lockbox нет по назначению: личный сейф паролей сотрудников, отчёт раскрытия при увольнении и кабинет для людей, которые не открывают консоль облака.
Если весь ландшафт в Yandex Cloud, а хранилище нужно только сервисам — берите Lockbox, это дешевле и надёжнее, чем администрировать своё.
Сведения о чужих продуктах взяты из их публичной документации и сайтов, сверено 01.09.2026. Что-то устарело или мы ошиблись — напишите на hello@wardhold.ru, поправим.
По пунктам
| Что сравниваем | Yandex Lockbox | Wardhold |
|---|---|---|
| Где работает | Внутри Yandex Cloud; снаружи — обращения по REST и gRPC с IAM-токеном | Где угодно: облако, своя виртуалка, закрытый контур без интернета, площадка заказчика |
| Доменная модель | Секрет, иммутабельные версии, активен и деактивирован, отложенное уничтожение версии | То же самое: модель повторена сознательно, чтобы переход не был переучиванием |
| Роли | Роли IAM облака: lockbox.viewer на метаданные, lockbox.payloadViewer на содержимое, lockbox.editor, lockbox.admin | Свои роли viewer, payloadViewer, editor — на проект и на отдельный секрет |
| Чем аутентифицируется потребитель | IAM-токеном; для кластера в него кладётся авторизованный ключ сервисного аккаунта облака (файл authorized-key.json) | Токеном wh_… со сроком и скоупом; в базе хранится только хеш |
| Kubernetes | Провайдер yandexlockbox в External Secrets Operator | Тот же оператор через generic webhook: плоский JSON и Bearer |
| Аудит чтения | События GetPayload уровня сервисов; собираются отдельным сервисом Audit Trails в бакет или лог-группу | Журнал каждого чтения и отказа виден в кабинете сразу, без подключения внешнего сервиса; сверху — карточка сотрудника |
| Пароли людей | Не задача сервиса | Личный сейф с шифрованием в браузере, генератор, одноразовые ссылки наружу |
| Шифрование | Ключами Yandex Key Management Service | AES-256-GCM с обязательным AAD; мастер-ключ локальный, внешние KMS — коммерческое издание |
| Лимиты | 10 000 секретов на облако, 1 000 версий на секрет, 64 КБ значений в версии | Ограничены вашей PostgreSQL |
| Деньги | 0,0274 ₽ за час хранения каждой версии (около 20 ₽ в месяц) плюс 3,79 ₽ за 10 000 операций get; тарифицируются и старые версии | Версии, чтения и потребители не тарифицируются: личное и Community бесплатны, коробка — бесплатно до ста сотрудников и 390 000 ₽ за инстанс до тысячи дальше, облачная организация — подписка |
| Эксплуатация | Ничего не обслуживаете: сервис управляемый | Обслуживаете бинарь и PostgreSQL; бэкап мастер-ключа — ваша ответственность |
| Отказоустойчивость | Ответственность провайдера, есть SLA | Ваша: резервирование и кластер — коммерческое издание |
| Переезд | API, CLI и провайдер Terraform внутри облака | Один и тот же API и формат данных в облаке и на своём сервере |
Когда что брать
Вопрос не в функциях, а в границе контура и в счёте
Модель одинаковая, поэтому выбирают по трём вещам: где физически стоит хранилище, кто его обслуживает и как растёт стоимость, когда версий становится много.
Логичнее взять Lockbox
- Весь ландшафт в Yandex Cloud и уезжать из него вы не планируете
- Хранилище нужно только сервисам, людям с паролями — отдельный инструмент
- Никто не хочет обслуживать ещё один компонент и отвечать за бэкап мастер-ключа
- Нужны ключи KMS, Audit Trails, Terraform и связка с управляемыми сервисами из коробки
- Секретов немного: полсотни версий стоят дешевле часа инженера
Логичнее взять Wardhold
- Контур закрытый, интернета может не быть, часть систем стоит у заказчика на площадке
- Один и тот же API нужен в облаке и на своём сервере: интеграции должны пережить переезд
- Нужны люди: сейф паролей, одноразовые ссылки, отчёт раскрытия при увольнении
- Журнал чтения нужен в интерфейсе сразу, а не через подключение отдельного сервиса аудита
- Версий много и они копятся: у нас хранение версии ничего не стоит
- Нужны MCP для AI-агентов и готовые сценарии 1С и Битрикс24
Что спросить обеим сторонам
- Сколько версий накопится за год и во что обойдётся их хранение?
- Где будут лежать пароли сотрудников и кто их увидит?
- Что произойдёт с интеграциями, если часть контура уедет из облака?
- Кто отвечает на вопрос «что читал уволенный подрядчик» и за сколько минут?
- Что происходит с доступом, когда авторизованный ключ сервисного аккаунта утёк вместе с манифестами?
Мирный вариант
Мы сами живём поверх Lockbox
Прод Wardhold развёрнут в Yandex Cloud, и корневые секреты самого инстанса — параметры доступа и ключевой материал — лежат именно в Lockbox: деплой забирает их по служебному аккаунту виртуальной машины. Это не компромисс, а естественное разделение слоёв.
Хранилище провайдера отвечает за пару корневых значений, которые меняются раз в год и которые читает только процесс развёртывания. Рабочее хранилище продукта отвечает за сотни секретов, их версии, роли, журнал чтения и людей. Смешивать эти два слоя невыгодно: в первом не нужен кабинет, во втором не нужен счёт за каждую версию.
Частые вопросы про это сравнение
Вы просто скопировали Lockbox?
Доменную модель — да, и это записано в наших решениях по архитектуре открытым текстом. Она проверена практикой, понятна инженерам и не требует объяснений на демонстрации. Совместимости API при этом нет: у нас свои адреса, свой формат ответа под External Secrets Operator и своя модель организаций и проектов вместо каталогов облака.
Как перенести секреты из Lockbox?
Скриптом: содержимое версии в Lockbox — это плоский набор пар «ключ — значение», ровно тот же вид, что принимает наш API при создании версии. Перенос сводится к обходу списка секретов и вызову создания версии у нас; ключи и имена сохраняются.
Что дешевле?
На малых объёмах — почти всегда Lockbox: платить за полсотни версий дешевле, чем администрировать свой сервис. Разница накапливается на росте: у нас не тарифицируются ни версии, ни чтения, ни число потребителей, зато появляются эксплуатация и подписка для организации. Считать надо суммарно и на год, а не за один секрет.
А если у нас другое облако?
Разбор почти дословно переносится на AWS Secrets Manager и Azure Key Vault: те же плюсы управляемого сервиса, та же привязка к провайдеру и то же отсутствие ответа на вопрос про пароли людей.
Другие сравнения
Пассворк
Корпоративный менеджер паролей, доросший до машинных секретов.
HashiCorp Vault и OpenBao
Динамические секреты, PKI и transit — задача шире нашей.
Bitwarden, 1Password и подобные
Менеджеры паролей для людей: расширение, приложения, автозаполнение.
Как есть сейчас
.env, переменные CI, константы 1С и переписка.
Считаете переезд из облака?
Напишите, сколько у вас секретов и версий и что их читает, — прикинем вместе и скажем, если оставаться в Lockbox выгоднее.