Налаштування управління секретами через 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