Настройка управления секретами через HashiCorp Vault

Мы помогаем компаниям избавиться от техдолга, связанного с хранением секретов в .env файлах и Kubernetes Secrets, внедряя HashiCorp Vault. Это не просто docker-compose up — это проектирование отказоустойчивого кластера, настройка auto-unseal, интеграция с CI/CD и обеспечение полного аудита доступа. Наши инженеры сертифицированы HashiCorp и имеют более 5 лет опыта работы с Vault. По данным исследований, 80% утечек данных связаны с компрометацией учётных данных, а средняя стоимость такой утечки превышает 4 миллиона долларов. Vault снижает этот риск на порядок, что при потенциальной экономии до 3,6 млн долларов на одном предотвращённом инциденте делает его незаменимым инструментом.

Vault решает задачу централизованного хранения, аудита доступа и ротации секретов. Но между "запустить Vault в Docker" и "production-ready Vault кластер" — дистанция в несколько дней работы. Рассмотрим ключевые аспекты, которые мы учитываем при внедрении.

Почему Vault лучше статических паролей?

В отличие от LastPass или 1Password, Vault не просто хранит пароли — он динамически генерирует временные учётные данные для баз данных, облачных сервисов и API. Например, при компрометации секрет живёт не дольше заданного TTL (обычно 1 час), после чего Vault автоматически отзывает его. Это снижает окно уязвимости в 144 раза по сравнению со статическими паролями, которые могут оставаться действительными неделями.

Архитектура: standalone vs HA-кластер

Для продакшена standalone-нода неприемлема: одна точка отказа, нет репликации, при рестарте Vault нужно распечатать вручную (unseal). Минимальная production-конфигурация — три ноды в HA-кластере с интегрированным Raft-хранилищем.

Конфигурация Vault (vault.hcl) для Raft HA:

ui = true
cluster_addr = "https://vault-1.internal:8201"
api_addr = "https://vault-1.internal:8200"

storage "raft" {
  path = "/opt/vault/data"
  node_id = "vault-1"

  retry_join {
    leader_api_addr = "https://vault-2.internal:8200"
  }

  retry_join {
    leader_api_addr = "https://vault-3.internal:8200"
  }
}

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file = "/opt/vault/tls/vault.key"
  tls_client_ca_file = "/opt/vault/tls/ca.crt"
}

seal "awskms" {
  region = "eu-central-1"
  kms_key_id = "alias/vault-unseal"
}

seal "awskms" — auto-unseal через AWS KMS. Критически важно для продакшена: без этого при каждом рестарте ноды нужен ручной ввод unseal-ключей. С auto-unseal Vault сам распечатывается при старте, используя KMS-ключ.

Как сервисы аутентифицируются в Vault?

Vault не работает по принципу «один логин/пароль для всех». Каждый клиент аутентифицируется через свой метод:

Kubernetes Auth — поды аутентифицируются через ServiceAccount JWT-токен. Vault проверяет подлинность токена через Kubernetes API.

vault auth enable kubernetes
vault write auth/kubernetes/config \
    kubernetes_host="https://kubernetes.default.svc" \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
vault write auth/kubernetes/role/myapp \
    bound_service_account_names=myapp \
    bound_service_account_namespaces=production \
    policies=myapp-policy \
    ttl=1h

AWS IAM Auth — EC2-инстансы и Lambda-функции аутентифицируются через IAM роль. Vault проверяет подпись через AWS STS GetCallerIdentity.

AppRole — для CI/CD систем, где нет встроенного метода аутентификации. Role ID хранится в системе CI, Secret ID генерируется динамически и действителен один раз (use_limit=1).

vault auth enable approle
vault write auth/approle/role/myapp policies=myapp-policy token_ttl=1h
# Получение Role ID и Secret ID
vault read auth/approle/role/myapp/role-id
vault write -force auth/approle/role/myapp/secret-id

Политики доступа: принцип минимальных привилегий

Каждое приложение получает только те секреты, которые ему нужны:

# policy: myapp-policy.hcl
path "secret/data/production/myapp/*" {
  capabilities = ["read"]
}

path "database/creds/myapp-role" {
  capabilities = ["read"]
}

# Запрет на листинг других секретов
path "secret/data/production/+/*" {
  capabilities = ["deny"]
}

Применить: vault policy write myapp-policy myapp-policy.hcl

Типичная ошибка: давать policy с path "secret/*" capabilities ["read", "list"]. Это означает, что скомпрометированный сервис получает доступ ко всему дереву секретов. RBAC через политики — единственный способ избежать этого.

Vault Agent: инъекция секретов в поды Kubernetes

Vault Agent Injector — sidecar-контейнер, который монтирует секреты как файлы в pod без изменения кода приложения. Аннотации на pod:

annotations: vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "myapp"
  vault.hashicorp.com/agent-inject-secret-config.env: "secret/data/production/myapp/config"
  vault.hashicorp.com/agent-inject-template-config.env: |
    {{- with secret "secret/data/production/myapp/config" -}}
    DATABASE_URL={{ .Data.data.db_url }}
    API_KEY={{ .Data.data.api_key }}
    {{- end }}

Секреты появляются в /vault/secrets/config.env. Приложение читает их как обычный файл. При ротации секретов Vault Agent обновляет файл и может сигнализировать приложению (SIGHUP) для reload конфигурации.

Audit log и мониторинг

Включение audit device — обязательный шаг в продакшене:

vault audit enable file file_path=/var/log/vault/audit.log 

Каждый запрос к Vault логируется: кто запросил, какой путь, timestamp, результат. Это основа для SOC-аналитики и реагирования на инциденты. Vault не запустится, если audit log недоступен для записи — это feature, не баг. HashiCorp Vault сертифицирован по стандарту SOC 2 Type II, подтверждающему надёжность хранения секретов.

Сравнение подходов к управлению секретами

Процесс внедрения

1. Аудит текущего хранения секретов — инвентаризация .env файлов, Kubernetes Secrets, конфигов CI/CD
2. Проектирование иерархии путей — структура secret/data/{env}/{service}/{key}, naming convention
3. Развёртывание Vault кластера — Terraform + Ansible, TLS, auto-unseal, инициализация
4. Настройка auth methods под стек (Kubernetes, AWS IAM, AppRole для CI)
5. Миграция секретов — поэтапно, сервис за сервисом, с проверкой
6. Документация и передача — runbook для операций: ротация root token, замена unseal-ключей, disaster recovery

Что входит в работу

• Развёрнутый Vault кластер (HA, auto-unseal, TLS)
• Настройка методов аутентификации (Kubernetes, AWS IAM, AppRole)
• Политики доступа для каждого сервиса
• Интеграция с CI/CD (GitLab CI, GitHub Actions)
• Vault Agent Injector для Kubernetes
• Audit log и мониторинг (Prometheus + Grafana)
• Документация и обучение команды
• Гарантия 3 месяца после внедрения

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Наши инженеры имеют сертификацию HashiCorp Certified: Vault Operations Professional и реализовали более 30 проектов по управлению секретами. Свяжитесь с нами для консультации — мы оценим вашу инфраструктуру и предложим оптимальное решение. Закажите внедрение Vault под ключ и избавьтесь от техдолга навсегда.

Wikipedia: HashiCorp Vault