Як я можу керувати секретами у форматі .tf та .tfstate?

Я хотів би скористатися провайдером Terraform MySQL, щоб зберегти список користувачів mysql та надавати корисні для створення нових тестових середовищ. .tfІ .tfstateфайли , як , здається, хочуть , щоб зберігати паролі MySQL в незашифрованому вигляді .

Щодо .tf:

Наскільки я розумію, що .tfфайли живуть під контролем редагування та підтримуються командою. Як ця практика відрізняється , коли секрети в .tf? Чи можна взагалі зашифрувати ці значення?

Щодо .tfstate:

Я можу .tfstateнадійно зберігати десь після запуску програми Terraform, але бажано, щоб цей випадок використання не зберігав його взагалі?

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і т. Д. ...

Ще кращою практикою було б генерувати ці секретні файли під час скрипту обгортки на основі даних у Сейфі чи іншим способом обміну секретами. Оскільки в даний час, коли змінюється формат секретів, або самі секрети, нам потрібно повідомляти його команді за межами каналу контролю версій - і це не завжди працює добре, якщо чесно. Але секрети змінюються нечасто.

Ми уникаємо терасової обробки своїх секретів. Навіть якщо вам вдасться ввести секрети за допомогою файлу var "secrtes.tfvars", як зазначено вище, ці секрети зберігатимуться у вашому терафорному (віддаленому) стані.

Ви можете захистити файли віддалених держав, використовуючи, наприклад, авторизацію S3, або ви можете ігнорувати локальні файли, але ми вирішили не покладатися на такий тип захисту.

Якщо ви перебуваєте на AWS, перегляньте "Правильний шлях управління секретами" від Segment.io в блозі AWS. Ми радимо використовувати chamberвсі наші клієнти для управління секретами. Він працює за допомогою використання магазину параметрів AWS Systems Manager Parameter Store (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-aws-kms-keyполегшити надання ключа KMS. Ознайомтеся з нашою детальною документацією з прикладами того, як використовувати chamberз кількома просторами імен, а також як використовувати камеру з тераформою для управління секретами. Дивіться наш повний довідковий приклад щодо забезпечення залежностей від камери.

Щодо того .tfstate, ви підкреслюєте дійсно хороший пункт про існування текстових секретів у файлі стану. Насправді цього не обійти. Для того, щоб тераформа підрахувала зміни для побудови плану, він повинен знати стан "до" і "після". З цієї причини рекомендуємо використовувати зашифроване відро S3 з обов’язковою версією. Використовуйте terraform-aws-tfstate-backendмодуль для забезпечення відра та таблиці блокування DynamoDB відповідно до кращих практик.

Щоб імпортувати секрети у файли .tf, ви також можете використовувати зовнішнє джерело даних . Це може бути, наприклад, скрипт, який розшифровує ваші секрети.

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