Как я могу управлять секретами в .tf и .tfstate?

Я хотел бы использовать Terraform MySQL Provider, чтобы вести список пользователей mysql и предоставлять удобные возможности для создания новых тестовых сред. .tfИ .tfstateфайлы , как , кажется, хотят , чтобы хранить пароли MySQL в незашифрованном виде .

По поводу .tf:

Насколько я понимаю, .tfфайлы находятся под контролем версий и поддерживаются командой. Как эта практика отличается, когда секреты в .tf? Можно ли вообще зашифровать эти значения?

Относительно .tfstate:

Я могу .tfstateбезопасно хранить где-нибудь после запуска Terraform apply, но было бы предпочтительным для этого случая использования вообще не хранить его?

Terraform поддерживает добавление дополнительного файла с переменными во время вызова.

^{документация: https://www.terraform.io/intro/getting-started/variables.html#from-a-file}

Мы используем эту функцию для предоставления secrets.tfvarsфайла при каждом вызове Terraform. Мы также используем сценарий, чтобы обернуть команду так, чтобы ее вызов был последовательным, и все члены команды избегали повторять одни и те же ошибки. Оболочка синхронизируется .tfstateс S3 перед выполнением и .tfstateвозвращает к S3 в конце. Я также слышал о людях, которые делают то же самое с состоянием, сохраненным в Консуле, даже добавляя в консул своего рода семафор, чтобы два человека не запускали Terraform одновременно.

Если вы избегаете установки значения по умолчанию в variables.tfфайле, это заставляет пользователя вводить значение. Он может быть введен вручную или с помощью -var-fileкоманды, как описано выше. Не устанавливайте по умолчанию свои секреты - это хороший способ обеспечить изменения, которые требуют изменения секретов.

secrets.tfvarsФайл является символической ссылкой на один из файлов с секретами , которые не хранятся в системе управления версиями. У нас есть несколько, по одному в каждой среде, как и secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvarsи т.д. ...

Еще лучше было бы создавать эти файлы секретов во время сценария оболочки на основе данных в Vault или каким-либо другим способом обмена секретами. Поскольку в настоящее время, когда формат секретов изменяется или сами секреты, нам необходимо сообщить об этом команде за пределами канала контроля версий - и это не всегда хорошо работает, если честно. Но секреты меняются нечасто.

Мы избегаем терраформ обращаться с нашими секретами. Даже если вам удастся ввести секреты с помощью файла var "secrtes.tfvars", как указано выше, эти секреты будут сохранены в вашем состоянии terraform (remote-).

Вы можете защитить файлы удаленного состояния, используя, например, авторизацию S3, или вы можете использовать файлы локального состояния gitignore, но мы решили не полагаться на этот вид защиты.

Если вы работаете в AWS, ознакомьтесь с «Правильным способом управления секретами» от Segment.io в блоге AWS. Мы рекомендуем использовать chamberдля всех наших клиентов для управления секретами. Он работает, используя хранилище параметров AWS Systems Manager (SSM) вместе с ключами KMS. Это гарантирует, что секреты зашифрованы в состоянии покоя (и в пути), защищены с помощью IAM, могут быть проверены с помощью CloudTrails и доступны только в качестве переменных среды во время выполнения.

После настройки камеры и настройки ключа KMS мы записываем секреты в хранилище параметров.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Затем используйте эти секреты, когда вызываете терраформ.

chamber exec db -- terraform plan

Это предполагает, что вы определили переменную с именем DB_USERи DB_PASSв вашем коде HCL.

Например, вы можете добавить это к variables.tf

variable "DB_USER" { }
variable "DB_PASS" { }

ПРИМЕЧАНИЕ: chamber всегда будет экспортировать переменные среды в верхнем регистре

Мы предоставляем модуль terraform, призванный terraform-aws-kms-keyупростить подготовку ключа KMS. Ознакомьтесь с нашей подробной документацией с примерами того, как использовать chamberнесколько пространств имен, а также как использовать камеру с терраформой для управления секретами. Смотрите наш полный справочный пример для обеспечения зависимостей камеры.

А что касается .tfstateдействительно хорошего вопроса о существовании секретов в виде простого текста в файле состояния. Там действительно нет никакого способа обойти это. Для того чтобы terraform рассчитал изменения для построения плана, ему необходимо знать состояние «до» и «после». По этой причине мы рекомендуем использовать зашифрованное ведро S3 с обязательным контролем версий. Используйте terraform-aws-tfstate-backendмодуль для предоставления корзины и таблицы блокировки DynamoDB в соответствии с рекомендациями.

Чтобы импортировать секреты в файлы .tf, вы также можете использовать внешний источник данных . Это может быть, например, скрипт, который расшифровывает ваши секреты.

Я посмотрел на несколько разных способов, но мне особенно понравился git-crypt для того, чтобы сделать что-то особенное, прежде чем реализовывать нечто большее, например Vault.