HashiCorp Vault или облачные менеджеры секретов AWS, GCP и Azure
Продвинутое4 минРедакция Innovialabs
Коротко
Если вся инфраструктура в одном облаке, а команда небольшая, берите встроенный менеджер секретов этого облака; Vault оправдан при мультиоблаке или своих серверах и когда нужны динамические секреты, а у команды есть ресурсы его поддерживать.
Коротко
- Облачный менеджер секретов (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) — управляемый сервис: не нужно ничего разворачивать, права и аудит встроены в облако. Лучший выбор для команды, живущей в одном облаке.
- HashiCorp Vault — отдельная платформа для секретов: динамические учётные данные, шифрование как сервис, единые политики для любых сред. Мощнее и гибче, но его нужно эксплуатировать или платить за управляемую версию.
Главный вопрос не «что лучше», а «сколько разных сред у вас и кто будет это поддерживать».
Сравнение по ключевым критериям
| Критерий | HashiCorp Vault | AWS Secrets Manager | GCP Secret Manager | Azure Key Vault |
|---|---|---|---|---|
| Динамические секреты | Да, для баз, облаков, PKI и других систем | Нет, только хранение и ротация | Нет | Нет |
| Ротация | Через lease и TTL, отзыв автоматически | Встроенная через Lambda, для ряда сервисов AWS — управляемая | Расписание с уведомлением в Pub/Sub, логику ротации пишете вы | Автоматическая для ключей; для секретов — через события Event Grid и свою функцию |
| Политики доступа | Свои политики в HCL, много методов аутентификации | IAM и resource policies | IAM | Azure RBAC |
| Аудит | Audit devices, нужно настроить и хранить | CloudTrail | Cloud Audit Logs | Диагностические логи в Azure Monitor |
| Работа вне облака | Где угодно: облака, свои серверы, Kubernetes | В основном внутри AWS | В основном внутри GCP | В основном внутри Azure |
| Эксплуатация | Высокая (self-hosted) или средняя (managed) | Минимальная | Минимальная | Минимальная |
Динамические секреты
Это главное отличие Vault. Вместо одного постоянного пароля к базе приложение при старте запрашивает у Vault временные учётные данные: Vault создаёт пользователя в базе с нужными правами и ограниченным сроком жизни (TTL). Когда срок истекает, Vault удаляет пользователя.
Что это даёт:
- у каждого экземпляра приложения — свой логин, по логам видно, кто что делал;
- утёкший пароль быстро перестаёт работать;
- не нужна отдельная процедура ротации — она встроена в модель.
Облачные менеджеры хранят статические секреты и умеют их менять по расписанию. Для многих проектов этого достаточно. Близкий эффект в облаке дают и роли: например, IAM-аутентификация в управляемых базах вместо паролей.
Ротация и аудит на практике
В облачных менеджерах ротация проще всего для «родных» сервисов облака, например управляемых баз. Для стороннего API-ключа почти везде придётся написать функцию, которая создаёт новый ключ у провайдера и сохраняет его как новую версию секрета.
Аудит у облаков включается вместе с остальными логами облака и попадает туда же, где уже смотрит команда. В Vault аудит нужно включить явно и решить, куда отправлять и как долго хранить журнал.
Стоимость и нагрузка на команду
Конкретные цены меняются, поэтому сравнивайте по факторам:
- Облачные менеджеры тарифицируются по числу секретов и/или количеству обращений к API. Счёт растёт, если приложение читает секрет при каждом запросе, — кешируйте значения в памяти. В AWS для простых конфигураций дешевле может оказаться Parameter Store.
- Vault self-hosted — это серверы, кластер для отказоустойчивости, бэкапы, обновления, процедура unseal, мониторинг и люди, которые понимают, как всё это восстановить в 3 часа ночи. Главная статья расходов — время инженеров.
- Управляемый Vault (HCP Vault) снимает эксплуатацию, но при небольшом числе секретов обычно обходится дороже облачных менеджеров.
Учтите лицензию: Vault распространяется по Business Source License. Если нужен полностью открытый вариант, существует форк OpenBao.
Что выбрать
| Ситуация | Рекомендация |
|---|---|
| Небольшая команда, всё в одном облаке | Встроенный менеджер секретов этого облака |
| Один VPS или несколько серверов без облака | Секреты CI/CD и хостинга; Vault пока избыточен |
| Несколько облаков или облако плюс свои серверы | Vault (managed или self-hosted) как единая точка |
| Строгие требования к доступу к базам и аудиту, есть платформенная команда | Vault с динамическими секретами |
| Kubernetes в любом облаке | Облачный менеджер или Vault плюс External Secrets Operator для синхронизации в кластер |
Начинать с облачного менеджера и переходить на Vault позже — нормальный путь. Если приложение читает секреты через переменные окружения или отдельный слой конфигурации, миграция займёт немного времени.
Частые ошибки
- Разворачивать Vault ради десятка статических секретов.
- Self-hosted Vault без бэкапов и плана восстановления: потеря ключей unseal означает потерю всех секретов.
- Один общий доступ «на всё» вместо политик под каждое приложение.
- Чтение секрета из облака при каждом HTTP-запросе вместо кеширования.