В Terraform-модуле переменная db_password помечена как sensitive = true, а в Ansible playbook пароль читается из Ansible Vault и используется в задаче подключения к БД. Команда считает, что после этих мер пароль нигде не виден в открытом виде. Что на самом деле скрывает sensitive в Terraform и no_log в Ansible, а что они не скрывают, и где пароль всё равно может оказаться в читаемом виде?

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

sensitive = true в Terraform скрывает значение переменной/output только в консольном выводе plan/apply (заменяет его на (sensitive value)), но само значение в открытом виде всё равно сохраняется в state-файле; аналогично no_log: true в Ansible скрывает значение из лога конкретной задачи, но не шифрует его — если значение передаётся через переменную, попадающую в другие незащищённые места (debug-задачи, артефакты CI, факты), оно может «утечь» в другом месте, поэтому обе меры дополняют, а не заменяют реальное шифрование секрета (Vault, Terraform state encryption, внешнее secret-хранилище).

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

механизм маскировки в обоих инструментах работает на уровне вывода/логирования: Terraform помечает конкретный атрибут как sensitive в своей внутренней модели и фильтрует его при рендере человеко-читаемого вывода, а Ansible для задачи с no_log: true просто не печатает параметры и результат этой задачи в лог; ни то, ни другое не меняет, как и где значение физически хранится (state на диске/в S3, временные файлы, память процесса).

Пример кода

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

variable "db_password" {
  type      = string
  sensitive = true
}
output "db_password" {
  value     = var.db_password
  sensitive = true
}
- name: Connect to DB
  community.mysql.mysql_user:
    login_password: "{{ vault_db_password }}"
  no_log: true

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

• Практика. для реальной защиты секретов state необходимо хранить в backend с шифрованием at rest (например, S3 с SSE) и ограниченным доступом, рассматривать вариант интеграции с внешним хранилищем секретов (Vault, AWS Secrets Manager) и подстановкой значения в момент apply, а не хранением «как есть»; в Ansible пароли лучше получать динамически (lookup в HashiCorp Vault/AWS Secrets Manager) вместо постоянного хранения в зашифрованном vault-файле в репозитории, если нужна ротация без изменения кода.

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

• Ошибка. частая ошибка — считать, что sensitive = true защищает значение в state-файле так же, как шифрование, и хранить незашифрованный state в общедоступном месте; другая ошибка — выводить sensitive-значение в Terraform через output без sensitive = true у самого output (тогда маскировка переменной не распространяется автоматически), либо в Ansible логировать результат задачи, использующей секрет, в отдельной debug-задаче без no_log, из-за чего пароль всё равно попадает в лог CI.