Секреты без боли: Vault, SOPS или KMS

Введение

Секреты начинают «болеть» не тогда, когда их много, а когда они живут дольше, чем должны, и оказываются не там, где ожидали: в Git‑истории, логах CI, артефактах сборки, файлах на bastion‑хосте. Самый быстрый способ убрать боль — правильно выбрать уровень абстракции: Vault как «секретный API» и фабрика динамических учеток, SOPS как удобное шифрование файлов для GitOps, KMS/Key Vault как корень доверия и управляемая криптография (и иногда — как хранилище секретов в облаке). Vault прямо позиционируется как identity‑based система управления секретами и шифрованием с аудитом и генерацией/ротацией учетных данных.  SOPS — CLI‑инструмент, который шифрует значения (обычно YAML/JSON/ENV) и «оборачивает» data key через KMS/PGP/age/в т.ч. Vault Transit. 

Короткая развилка по практике:

• Если вам нужны динамические секреты с TTL, отзывом и аудитом (DB‑учетки, временные токены, «секреты по запросу») — чаще всего выигрывает Vault. Динамические секреты в Vault опираются на lease/TTL и автоматический revoke. 
• Если вы живете в GitOps и хотите хранить «секретный YAML» прямо в репозитории без отдельного сервера — SOPS + KMS/Key Vault/PGP/age дает лучший UX и быстрый вход. Flux прямо описывает этот сценарий и поддерживаемые KMS‑бэкенды (AWS KMS, GCP KMS, Azure Key Vault, OpenPGP). 
• Если вы в первую очередь решаете задачу управления ключами шифрования (CMEK, envelope encryption, унификация IAM‑доступа) — облачный KMS как управляемый сервис будет базовым кирпичом; но важно помнить, что, например, AWS KMS не хранит ваши data keys и не является «менеджером паролей». 

Что на самом деле сравниваем

Технически Vault, SOPS и KMS — не «три конкурента», а три разных слоя одной истории.

KMS — это про ключи и криптооперации. AWS KMS генерирует и расшифровывает data keys, но не хранит/не трекает их и не шифрует ваши данные «сам по себе» — вы делаете это через envelope encryption или отдаете задачу сервисам вроде S3/EBS/RDS.  В Google Cloud это формализовано отдельным паттерном «envelope encryption»: KEK (в KMS) шифрует DEK (data encryption key), а DEK шифрует данные. Azure Key Vault шире: он умеет хранить secrets (пароли, connection strings, storage keys) как объект первого класса. 

SOPS — это про зашифрованные файлы и удобный Git‑workflow. Он генерирует случайный data key (256‑бит), шифрует значения AES‑256‑GCM, а затем просит KMS/PGP/age/Key Vault/в т.ч. Vault Transit зашифровать этот data key и кладет «обёртки» в метаданные файла.  Отсюда эффект: секреты можно хранить хоть в Git, хоть в S3 — пока файл зашифрован, носитель не так важен.

Vault — это про выдачу секретов как сервис и жизненный цикл. Vault считает storage backend «недоверенным» и шифрует данные до записи за пределы криптографического барьера.  Кроме статического KV, он умеет «динамику»: выдавать креды «под роль» и отзывать их по TTL/lease. 

В результате правильный вопрос звучит не «что лучше», а «когда секрет должен появиться в plaintext, на каком узле и на какой срок». Чем ближе plaintext к runtime и чем короче TTL — тем меньше боли.

HashiCorp Vault: секреты как сервис

Архитектура и модель данных. Vault — серверная система с HTTP API/CLI, ядром (Core), подсистемой аутентификации, policy‑движком и secrets engines. Secrets engines монтируются в пути и обрабатывают запросы по префиксу пути.  Данные уходят в storage backend (Consul/raft и др.), который считается недоверенным, поэтому Vault шифрует перед записью, а при чтении верифицирует целостность. 

Шифрование «в покое» и «в транзите». Внутренний «security barrier» Vault автоматически шифрует данные, уходящие в backend, AES‑256‑GCM (с 96‑битными nonce) и проверяет GCM‑tag на подмену.  Для данных «в транзите» (или когда вы хотите криптографию как сервис) есть Transit secrets engine: Vault выполняет криптооперации и не хранит отправленные данные, что удобно для tokenization/подписей/шифрования payload‑ов. 

Доступ и модели RBAC/ABAC. Vault «deny by default»: пустая политика ничего не разрешает.  Политики описывают разрешения на пути (capabilities, близкие к HTTP verbs).  Это естественный RBAC‑скелет, а «почти‑ABAC» появляется через policy templating (подстановка атрибутов identity в правилах). 

Ротация, TTL и отзыв. Сильная сторона Vault — жизненный цикл. Для динамических секретов и service‑type токенов Vault создает lease (TTL, renewability), по истечении lease автоматически revoke; при revoke токена отзываются и все leases, созданные этим токеном.  Для баз данных есть Database secrets engine, который генерирует креды по ролям через плагины. 

HA, масштабирование, операционка. В HA‑режиме Vault имеет состояние active/standby: активен один, остальные — горячие standby.  Для упрощения инфраструктуры есть Integrated Storage (Raft): не требует внешних систем, реплицирует данные консенсусом и поддерживает HA/backup‑restore.  Для запуска нужен процесс seal/unseal; авто‑unseal можно сделать через облачный KMS/HSM. 

Аудит и расследования. Vault audit devices пишут полный request/response для взаимодействий, но по умолчанию хэшируют большинство строк HMAC‑SHA256 (чтобы не хранить секреты в логах).  HashiCorp рекомендует включать минимум два audit device, чтобы аудит не стал SPOF. 

Стоимость владения и «скрытая цена». Vault часто дешевле по лицензии, чем по времени команды: bootstrap, политики, обновления, бэкапы, процедуры «break glass», etc. Дополнительно учтите лицензионный контекст: HashiCorp объявила переход с MPL 2.0 на Business Source License (BSL 1.1) для будущих релизов продуктов.  Если вы используете Vault Enterprise, лицензия имеет даты начала/окончания; после истечения вы не сможете запускать/обновляться на версии, выпущенные позже срока, включая security fixes. 

Короткие примеры команд (минимально жизненно‑необходимые):

# KV: запись (KV v2 создаёт новую версию секрета)vault kv put secret/app db_user="app" db_pass="REDACTED"   # # Transit: включить "криптографию как сервис" и создать ключvault secrets enable -path=transit transit                 # vault write transit/keys/payments type=chacha20-poly1305    # (тип ключа — пример)# Lease: отзыв выданного секрета/учётки по lease_idvault lease revoke <lease_id>

Mozilla SOPS: секреты как зашифрованные файлы

Архитектура. SOPS — «безсерверный» подход: CLI делает всё локально (или в CI), а ключи живут в выбранном механизме (KMS/Key Vault/PGP/age/Vault). При создании файла SOPS генерирует случайный 256‑битный data key и просит каждый master key зашифровать его; затем шифрует значения в дереве документа AES‑256‑GCM. 

Модель секретов и UX. SOPS шифрует значения, оставляя ключи открытыми — это делает diffs читаемыми и позволяет понимать структуру секрета без утечки значений.  Для целостности SOPS считает MAC по содержимому (и структуре) и хранит его зашифрованным.  Практический вывод: SOPS отлично ложится на Git‑review и GitOps, где важны «человеческие» изменения и проверка PR до деплоя.

Доступ (RBAC/ABAC) и куда делся контроль. В SOPS контроль доступа почти полностью делегирован в выбранный KMS/IAM (или в управление PGP/age ключами). Это плюс (используете зрелый IAM), но и минус: вам нужно одинаково хорошо уметь в IAM‑политики и в дисциплину CI. SOPS прямо поддерживает, например, AWS KMS encryption context — как дополнительный сигнал для IAM/Key policy ограничений. 

Ротация. Важная деталь: SOPS умеет ротацию именно data key файла. Команда rotate генерирует новый data key и заново шифрует значения; updatekeys — добавляет/убирает master keys без ротации data key.  Есть «key groups» — режим, где для расшифровки требуется несколько групп master keys (Shamir secret sharing для data key), что полезно для break‑glass и разделения ответственности. 

CI/CD и GitOps. Flux описывает типовую механику: хранить Kubernetes Secret манифесты в Git, но зашифрованными SOPS (с бэкендом OpenPGP/AWS KMS/GCP KMS/Azure Key Vault).  Здесь «боль» обычно живёт в двух местах: (а) кто и где может расшифровать, (б) как гарантировать, что plaintext не попадёт в логи/артефакты.

Аудит. Не все знают, но SOPS может писать audit‑события о расшифровке в заранее настроенную PostgreSQL‑БД (когда это нужно для контролируемой среды). 

Короткие примеры:

# Шифрование/дешифрование файлаsops encrypt -i k8s/secret.yamlsops decrypt k8s/secret.yaml > /dev/stdout# Ротация data key "на месте"sops rotate -i k8s/secret.yaml                               # # Подключение Azure Key Vault key как master key (пример из документации)sops encrypt --azure-kv https://sops.vault.azure.net/keys/sops-key/ test.yaml > test.enc.yaml  # 

И ещё один важный мостик: SOPS может использовать Vault Transit как мастер‑ключ (когда Vault уже есть, а GitOps‑файлы тоже хочется). Документация SOPS прямо показывает включение отдельного transit‑mount и шифрование через --hc-vault-transit. 

Облачные KMS и Azure Key Vault: ключи как управляемый сервис

Главное уточнение терминов.- AWS KMS и Google Cloud KMS — прежде всего про ключи и криптооперации. AWS KMS, например, возвращает plaintext data key (для использования вне KMS) и зашифрованную копию data key, которую можно хранить рядом с данными; при этом KMS не хранит ваши data keys и не выполняет операции с ними «за вас». - Azure Key Vault также умеет хранить secrets (пароли, connection strings, storage account keys) как отдельный объект. 

Управление доступом: RBAC + ABAC.- В AWS контроль доступа к KMS ключам складывается из key policy, IAM policies, grants (и при необходимости — VPC endpoint policies).  ABAC в AWS обычно строят через теги и IAM Condition‑правила. - В Google Cloud KMS доступ управляется IAM‑ролями, а ABAC‑условия делаются через IAM Conditions (условные role bindings). - В Azure Key Vault есть два «плана»: control plane и data plane; аутентификация через Microsoft Entra ID, а авторизация — через Azure RBAC (рекомендовано) или legacy access policies.  Для ABAC в Azure есть role assignment conditions (Azure ABAC). 

Шифрование и envelope encryption. В Google Cloud envelope encryption выделен как канонический паттерн и подробно описан: KEK в KMS, DEK у приложения/сервиса.  В AWS похожая логика отражена в документации по data keys/GenerateDataKey: зашифрованная копия DEK хранится с данными, а KMS расшифровывает её по запросу.  В Azure Key Vault есть операции wrap/unwrap для ключей (типичный envelope‑сценарий — «оборачивать» локальный CEK ключом из Key Vault). 

Ротация: ключи и секреты — это разные плоскости.- AWS KMS поддерживает автоматическую/он‑деманд ротацию ключевого материала для симметричных customer managed keys; при этом ротация не «перешифровывает» уже защищённые данные и не ротирует data keys, которыми вы шифровали контент. - Google Cloud KMS при rotation создает новые key versions; данные, зашифрованные старой версией, не перешифровываются автоматически, а старые версии продолжают «жить» (и могут влиять на стоимость), пока вы их не уничтожите. - Azure Key Vault поддерживает auto‑rotation для криптографических keys через rotation policy.  И отдельно — есть практики/туториалы по автоматизации ротации secrets (например, для ресурсов с одним набором учетных данных). 

Стоимость владения (TCO) и что «капает» по счёту.- AWS KMS pricing включает стоимость ключей/операций; отдельно отмечено, что первые две ротации key material добавляют $1/месяц (с ограничением на вторую), дальше доплата за ротации не растёт. - Google Cloud KMS pricing: создание новой key version как административная операция — бесплатно; но re‑encrypt (криптооперации) учитываются в биллинге. - Azure Key Vault: операции над secrets/keys/certificates тарифицируются по операции (например, $0.03 за 10,000 операций для базовых операций; отдельные тарифы — для certificate renewals). 

Таблица сравнения и ключевые trade-offs

Оценки ниже — практические (качественные), потому что «безопасность» и «удобство» зависят от выбранного threat model, зрелости IAM и дисциплины CI/CD. Но как ориентир для выбора — работает.

Практический вывод для инженерных команд:Vault выигрывает там, где важна динамика и отзыв (и где вы хотите убить «вечные» секреты как класс). SOPS выигрывает там, где вы хотите не заводить сервер и у вас уже есть зрелый IAM/KMS, а GitOps — основной способ доставки изменений. KMS/Key Vault — фундамент почти везде, но сам по себе KMS редко закрывает «секреты приложения» end‑to‑end без дополнительных компонентов. 

Архитектура CI/CD и GitOps

Ниже — типовая схема, которая показывает, как эти подходы обычно сочетаются (а сочетание часто лучше «единственно правильного» инструмента).

flowchart LR  Dev[DevOps/SRE инженер] -->|PR/commit| Git[(Git repo)]  Git --> Enc[Зашифрованные манифесты\nSecrets/values (SOPS)]  subgraph CI[CI/CD]    Runner[CI runner]    Render[Render/validate\nHelm/Kustomize]  end  Git --> Runner  Runner -->|Workload identity\nOIDC/WIF/IRSA| IAM[Cloud IAM]  IAM --> KMS[(AWS KMS / GCP KMS\n/ Azure Key Vault Keys)]  Runner -->|sops -d| Render  Render -->|apply/deploy| Cluster[(Kubernetes / VMs)]  subgraph Runtime[Runtime secrets]    Vault[(Vault HA Cluster)]    Storage[(Raft/Consul storage)]    Agent[Vault Agent / ESO / VSO]  end  Vault --> Storage  Vault -->|auto-unseal| KMS  Cluster --> Agent  Agent -->|get/renew secrets| Vault

Связки в этой схеме подтверждаются документацией:

• Flux описывает хранение зашифрованных Kubernetes secrets в Git и расшифровку через SOPS с использованием AWS KMS/GCP KMS/Azure Key Vault/OpenPGP. 
• Vault Agent Injector — admission webhook, который добавляет init/sidecar контейнеры Vault Agent в Pod’ы для потребления секретов. 
• External Secrets Operator интегрирует внешние secret‑системы (включая Vault и Azure Key Vault) и синхронизирует значения в Kubernetes Secret. 

Где чаще всего появляется «боль» в CI/GitOps:

• Где происходит расшифровка? Чем ближе к runtime (в кластере/на узле назначения), тем меньше шанс утечек в CI‑артефакты. Но тем выше требования к in‑cluster IAM и hardening контроллеров.
• Как устроены плагины/контроллеры? Например, в Argo CD Vault Plugin есть прямое предупреждение: сгенерированные манифесты с секретами могут кэшироваться (Redis/repo‑server), и это влияет на threat model. 
• Насколько вы доверяете Git как журналу? Если секрет однажды попал в историю, «удалить без следов» сложно: GitHub прямо отмечает, что удаление из истории требует координации со всеми, у кого есть клон/форк. 

Выводы, риски и рекомендации

Риски, которые реально встречаются:

• Секреты в Git‑истории. Даже если вы удалили файл из текущего состояния репозитория, он может остаться в истории/форках; чистка — отдельная операция с последствиями. 
• «Ротация включена» ≠ «данные перешифрованы». И AWS KMS, и Google Cloud KMS прямо подчеркивают, что создание новой версии/ротация не перешифровывает существующие данные автоматически (и в GCP старые версии еще и могут продолжать стоить денег, пока активны). 
• Секреты как «вечные значения». SOPS прекрасно защищает файл, но не делает секрет короткоживущим: если вы храните статический пароль, он останется статическим, просто зашифрованным. Решение обычно — миграция на динамику (Vault) или хотя бы регулярная autorotation. 
• Ротация без простоя. Для production‑систем полезна «blue/green» ротация: держать две версии секрета и переключать потребителей без даунтайма. 

Лучшие практики, которые снижают боль сильнее, чем выбор инструмента:

Сделайте так, чтобы plaintext появлялся как можно позже и жил как можно меньше. Для Vault это естественно через lease/TTL и revoke.  Для SOPS это означает: дешифровать только в момент деплоя, не сохранять в артефакты, не печатать в логи, минимизировать доступ раннеров.

Дайте доступ не «команде», а workload identity. В облаке это обычно условные/контекстные политики (ABAC) — теги и условия в AWS IAM, IAM Conditions в GCP, role assignment conditions в Azure.  Это дисциплинирует модель: кто именно и из какого окружения может расшифровать/получить секрет.

Выберите «точку истины» для прод‑секретов и будьте последовательны. Практичный шаблон миграции выглядит так:

• Шаг первый: убрать plaintext из Git и автоматизировать доставку — часто проще всего через SOPS + KMS, потому что меняется только workflow вокруг файлов. 
• Шаг второй: когда созреет потребность в TTL/динамике/аудите — выделить Vault как runtime‑источник, а SOPS оставить для bootstrap (например, чтобы доставить параметры подключения к Vault или минимальные токены/roles). Vault при этом можно auto‑unseal через облачный KMS. 
• Шаг третий: регулярно проверять, что ротация не «псевдо‑ротация». Если ключи/версии обновляются, но данные остаются под старой версией — планируйте re‑encrypt там, где это важно. 

Итоговая рекомендация «без боли».Если вы выбираете один инструмент «навсегда», почти наверняка боль останется. Самая практичная архитектура для большинства команд выглядит как KMS/Key Vault (root‑of‑trust) + SOPS (GitOps‑слой) + Vault (runtime‑динамика там, где она окупается). Это не усложнение ради усложнения: это разделение ответственности по жизненному циклу секрета — и именно оно обычно превращает управление секретами из бесконечной нервотрёпки в скучную, предсказуемую рутину.