Секреты (пароли БД, API-ключи сторонних сервисов) сейчас хранятся в зашифрованных Ansible Vault файлах в git и в Terraform-переменных, помеченных sensitive, но недавний аудит обнаружил, что несколько секретов не менялись три года и известны бывшим подрядчикам. Как спроектировать архитектуру управления секретами для связки Terraform + Ansible + Kubernetes/Helm, которая обеспечивает ротацию и минимизирует распространение секретов в state/git, и какие компромиссы это создаёт по сравнению с текущим подходом?

Короткий ответ

Нужно перейти от статичного хранения секретов в зашифрованных файлах к централизованному secret-хранилищу (например, HashiCorp Vault или облачный аналог) с динамической выдачей короткоживущих секретов: Terraform получает секреты через data source к Vault в момент apply (не храня их постоянно в конфигурации), Ansible — через community.hashicorp_vault lookup вместо расшифровки статичного vault-файла, а Kubernetes/Helm — через внешний secret-оператор (например, External Secrets Operator), синхронизирующий секреты из Vault в Kubernetes Secrets во время выполнения, а не зашитый в values чарта; это не устраняет полностью присутствие секрета в state (многие ресурсы всё равно требуют записи значения в state провайдером), но резко снижает время жизни скомпрометированного значения за счёт ротации.

Как это работает подробнее

динамические секреты в Vault выдаются с ограниченным TTL и привязаны к конкретной роли/политике доступа, поэтому даже утечка значения ограничена по времени его действия, а не живёт годами, как статичный пароль в зашифрованном файле; интеграция на уровне Terraform/Ansible/Kubernetes через единый источник означает, что ротация настраивается и аудируется в одном месте, а не в трёх разных местах с разными процессами, как сейчас.

Сравнение

• Компромисс. Статичные зашифрованные секреты проще внедрить и не требуют поддержки дополнительного сервиса, но не решают проблему ротации и долгоживущего доступа бывших сотрудников/подрядчиков; динамическая выдача через Vault даёт ротацию и централизованный аудит, но добавляет операционную нагрузку (ещё один критичный сервис, который сам нуждается в HA и DR) и не покрывает legacy-компоненты без доработки. Решение должно соответствовать реальной критичности секретов и зрелости команды эксплуатировать дополнительный сервис, а не внедряться как разовая "модная" миграция без плана поддержки.

Пример кода

main.tfКопировать

# Terraform: получение секрета из Vault в момент apply, без хранения пароля в коде
data "vault_generic_secret" "db" {
  path = "database/creds/app-role"
}
resource "aws_db_instance" "app" {
  password = data.vault_generic_secret.db.data["password"]
}
# External Secrets Operator: секрет синхронизируется в Kubernetes Secret из Vault
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-db-credentials
spec:
  secretStoreRef:
    name: vault-backend
  target:
    name: app-db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: database/creds/app-role
        property: password

Что использовать на практике

• Практика. такой переход требует значимых инвестиций: разворачивание и эксплуатация самого Vault (или выбор managed-альтернативы), миграция существующих секретов и процессов, обучение команд новым инструментам, и для части legacy-систем, не поддерживающих динамическую выдачу, всё равно потребуется какой-то статичный секрет с процессом ручной ротации; поэтому миграцию стоит вести поэтапно, начиная с самых критичных и самых старых (как в аудите) секретов.

Подводные камни

• Ошибка. Не выполняйте изменение без проверки плана, резервной копии состояния и понятного способа отката; для production согласуйте окно работ и исключите параллельные операции.