Управление секретами и Vault

01Что считается секретом и почему .env-файлов недостаточно

Секрет — всё, что даёт доступ: пароли от баз, API-ключи платёжных и почтовых провайдеров, OAuth client secrets, ключи подписи JWT, приватные ключи TLS, SSH-ключи, ключи шифрования и секреты подписи вебхуков. Подход Twelve-Factor — хранить конфигурацию в переменных окружения — был большим шагом вперёд по сравнению с хардкодом, и .env-файлы на сервере по-прежнему разумное начало. Но по мере роста системы появляются проблемы: копии одного и того же .env на ноутбуках, в CI и на серверах; нет записи о том, кто что читал; нет простой ротации; секреты видны в списках процессов, crash dump или страницах ошибок; и вечный риск закоммитить файл. Управление секретами решает это, относясь к секретам как к данным с владельцем, политикой доступа, аудит-логом и жизненным циклом.

• Никогда в Git, Docker-образах, клиентских бандлах или логах
• У каждого секрета есть владелец, scope и план ротации
• Доступ выдаётся по идентичности и записывается

02Как работает secret manager

Представьте банковское хранилище с охранником и журналом. Secret manager хранит секреты зашифрованными at rest, обычно под ключом, защищённым облачным KMS или аппаратным модулем безопасности (HSM). Приложения аутентифицируются по идентичности — облачной IAM-роли, Kubernetes service account, OIDC-токену CI-задачи или AppRole, — а не по общему паролю. Политики сопоставляют идентичности с путями, которые им можно читать: сервис orders может читать secret/prod/orders/* и ничего больше. Каждое чтение и запись попадают в аудит-лог. Основные варианты: HashiCorp Vault (с 2023 года source-available под лицензией BSL, теперь часть IBM), OpenBao (open-source форк Vault под эгидой Linux Foundation), облачные сервисы вроде AWS Secrets Manager, Google Secret Manager и Azure Key Vault, а также платформы для разработчиков вроде Doppler, Infisical или 1Password Secrets Automation.

03Основы Vault: KV-секреты и политики

Vault организует всё по путям. Secrets engine key/value (KV) хранит статические секреты с версионированием, так что можно откатиться. Политики на HCL выдают на пути capabilities вроде read, create, update или list. Приложения входят через auth method, соответствующий месту, где они работают, — kubernetes, aws, jwt/oidc для CI или approle — и получают короткоживущий Vault-токен, ограниченный политикой. Режим разработки (vault server -dev) — только для обучения: он работает в памяти, unsealed, с root-токеном. Продакшену нужны хранилище (обычно выбирают integrated Raft storage), TLS, auto-unseal через облачный KMS или HSM, включённые audit devices и отозванный после настройки root-токен. Те же команды работают с CLI bao от OpenBao.

1# Store and read a versioned secret (KV v2)
2vault kv put secret/prod/orders db_password='use-a-generated-value'
3vault kv get -field=db_password secret/prod/orders
4 
5# orders-policy.hcl — read-only access to one app's secrets
6path "secret/data/prod/orders/*" {
7  capabilities = ["read"]
8}
9 
10vault policy write orders orders-policy.hcl
11vault audit enable file file_path=/var/log/vault_audit.log

04Динамические секреты: учётные данные, которые истекают сами

Самая сильная идея Vault — динамические секреты. Вместо одного долгоживущего пароля от базы, общего для всех инстансов, Vault по запросу создаёт уникального пользователя базы для каждого инстанса приложения с lease — скажем, на час. Когда lease истекает или отзывается, Vault удаляет этого пользователя. Утёкшие учётные данные быстро становятся бесполезными, каждое подключение можно отнести к конкретному инстансу, а отзыв доступа у скомпрометированного сервиса — одна команда. Тот же паттерн есть для облачных учётных данных (временные ключи AWS), PKI (короткоживущие TLS-сертификаты) и SSH (подписанные сертификаты вместо authorized keys). Облачные провайдеры предлагают похожие идеи нативно: IAM-роли для нагрузок и IAM-аутентификация в базе вообще избавляют от хранимых паролей. Приложения должны обрабатывать продление, и это за вас делают клиентские библиотеки и агенты вроде Vault Agent.

1# One-time setup by an admin
2vault secrets enable database
3vault write database/config/app-db plugin_name=postgresql-database-plugin \
4  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/app" \
5  allowed_roles="orders-ro" username="vault_admin" password="initial-admin-pass"
6vault write -force database/rotate-root/app-db   # Vault now owns the admin password
7 
8vault write database/roles/orders-ro db_name=app-db default_ttl=1h max_ttl=24h \
9  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
10 
11# Each app instance asks for its own short-lived user
12vault read database/creds/orders-ro

05Как доставлять секреты в приложения

Есть три распространённых паттерна доставки. Прямой API: приложение через SDK читает секреты при старте и продлевает lease — гибко, но связывает код с хранилищем. Sidecar или агент: Vault Agent (или облачный аналог) аутентифицируется, получает секреты и рендерит их в файл или окружение для приложения, автоматически продлевая; приложение просто читает файл. Синхронизация платформой: в Kubernetes External Secrets Operator или Secrets Store CSI driver синхронизируют секреты из secret manager в поды. В CI/CD вообще не храните долгоживущие облачные ключи: GitHub Actions, GitLab и другие могут выпускать OIDC-токен на каждую задачу, который облако или Vault обменивает на короткоживущие учётные данные. Для Docker Compose на VPS простой и надёжный паттерн — env-файлы, принадлежащие root, с правами 600 вне репозитория, или Docker secrets, смонтированные как файлы.

1# GitHub Actions: no stored cloud keys — exchange the job's OIDC token
2permissions:
3  id-token: write
4  contents: read
5jobs:
6  deploy:
7    runs-on: ubuntu-latest
8    steps:
9      - uses: aws-actions/configure-aws-credentials@v4
10        with:
11          role-to-assume: arn:aws:iam::123456789012:role/deploy-prod
12          aws-region: eu-central-1
13      - run: aws secretsmanager get-secret-value --secret-id prod/orders --query SecretString --output text > /dev/null

06Ротация, минимальные привилегии и реакция на утечку

Ротация — это замена секрета новым по расписанию и после любого подозрения на утечку. Чтобы ротировать без простоя, поддерживайте две действующие версии одновременно: создайте новые учётные данные, задеплойте их, убедитесь, что старые никто не использует, затем отзовите старые. Облачные secret manager умеют автоматизировать ротацию для баз; для сторонних API-ключей ротация обычно оформляется как скриптовый runbook. Минимальные привилегии означают, что каждый сервис, человек и пайплайн получают только нужные им секреты, в нужном окружении и в идеале только на чтение. Профилактика: запускайте сканеры секретов вроде gitleaks или TruffleHog в pre-commit-хуках и CI и включите push protection на вашем Git-хостинге. Когда секрет утёк, важен порядок: сначала отзовите или ротируйте его, потом удаляйте из истории, потому что переписывание истории Git не «отменяет утечку» ключа, который уже склонировали или собрали ботами.

• Ротация: создать новый → задеплоить → проверить → отозвать старый
• Сканирование: pre-commit + CI + push protection
• Утечка: сначала отзыв, затем чистка истории, затем разбор логов доступа

07Архитектура Vault: seal, хранилище и высокая доступность

Модель безопасности Vault держится на барьере: всё, что уходит из Vault в хранилище, зашифровано keyring, защищённым root-ключом. Sealed означает, что Vault не держит ключей в памяти. При Shamir unseal root-ключ разбивается на доли (например, пять, из которых нужны три), которые хранят разные люди; при auto-unseal облачный KMS или HSM расшифровывает его автоматически при старте — это норма в продакшене, потому что перезапуски не должны требовать людей посреди ночи. Integrated storage (Raft) реплицирует данные обычно на три или пять узлов; один — лидер, остальные — standby, которые пересылают запросы, а для записи нужен кворум. Делайте бэкапы через Raft snapshots и тестируйте восстановление. Редакции Enterprise и HCP добавляют performance- и disaster-recovery-репликацию между регионами. С точки зрения эксплуатации Vault — инфраструктура tier-zero: если он лежит, приложения не могут стартовать, поэтому продумайте кэширование, разумные сроки lease и мониторинг статуса seal, смены лидера и числа lease.

1# Production-style server config (excerpt)
2storage "raft" {
3  path    = "/opt/vault/data"
4  node_id = "vault-1"
5}
6listener "tcp" {
7  address       = "0.0.0.0:8200"
8  tls_cert_file = "/etc/vault/tls/vault.crt"
9  tls_key_file  = "/etc/vault/tls/vault.key"
10}
11seal "awskms" {
12  region     = "eu-central-1"
13  kms_key_id = "alias/vault-unseal"
14}
15api_addr     = "https://vault-1.internal:8200"
16cluster_addr = "https://vault-1.internal:8201"

08Secret zero: как доверять первым учётным данным

Любая система секретов сталкивается с проблемой «secret zero»: чтобы получить секреты, приложение сначала должно аутентифицироваться — а каким секретом для этого пользоваться? Современный ответ — опираться на идентичность, которую уже подтверждает платформа. В AWS роль инстанса или задачи подписывает запрос, который Vault или Secrets Manager могут проверить. В Kubernetes projected service-account token пода проверяется кластером. В CI OIDC-токен задачи подписан CI-провайдером. На голых VPS такой идентичности платформы нет, поэтому варианты — AppRole с role id, зашитым в конфигурацию, и secret id, который инструмент деплоя доставляет один раз с коротким TTL и однократным использованием, или клиентский TLS-сертификат, выданный при провиженинге. Что бы вы ни выбрали, привязывайте идентичность к узким политикам и коротким токенам и делайте bootstrap-учётные данные бесполезными после первого использования.

09Шифрование как сервис и envelope encryption

Помимо хранения секретов, transit engine в Vault и облачные KMS шифруют данные для приложений, никогда не раскрывая ключ. Приложение отправляет plaintext, получает ciphertext и хранит его в своей базе; расшифровка требует вызова, проверяемого политикой. Ключи можно ротировать, при этом старые шифротексты остаются расшифровываемыми и их можно перешифровать под новую версию. Для больших данных используйте envelope encryption: сгенерируйте случайный data key, локально зашифруйте им данные (например, AES-256-GCM), затем зашифруйте data key ключом KMS и храните рядом с данными. Вы получаете быстрое локальное шифрование, централизованный аудит и возможность отрезать доступ, отключив один мастер-ключ. На этом паттерне построены шифрование персональных данных на уровне полей, зашифрованные бэкапы и секреты в GitOps-инструментах вроде SOPS.

1# Transit: the app never sees the key
2vault secrets enable transit
3vault write -f transit/keys/customer-pii
4 
5vault write transit/encrypt/customer-pii plaintext=$(printf '%s' 'AM12345678' | base64)
6# -> ciphertext: vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==
7 
8vault write transit/decrypt/customer-pii ciphertext='vault:v1:8SDd3WHDOjf7...'
9vault write -f transit/keys/customer-pii/rotate   # new version, old data still readable

10Секреты в Kubernetes: чем не является base64

Kubernetes Secret закодирован в base64, а не зашифрован; любой, кто может читать Secrets в namespace или читать бэкапы etcd, видит значения. Укрепляйте защиту слоями. Включите шифрование etcd at rest, в идеале через KMS-провайдера. Ограничьте RBAC так, чтобы get или list для Secrets могли делать только нуждающиеся в них нагрузки и немногие операторы, — «list» на Secrets фактически раскрывает их все. Не коммитьте манифесты Secret в Git; используйте External Secrets Operator для синхронизации из центрального хранилища или Sealed Secrets либо SOPS для GitOps, где значения зашифрованы в репозитории. Предпочитайте монтировать секреты как файлы, а не переменные окружения, — так значения можно ротировать без перезапуска и они реже попадают в crash dump. Наконец, используйте workload identity, чтобы поды могли вызывать облачные API и secret manager вообще без статических ключей в Secrets.