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


46

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

Щодо .tf:

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

Щодо .tfstate:

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

Відповіді:


22

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

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



8

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

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


2
Також перевірте github.com/hashicorp/terraform/isissue/516 , де саме вони відстежують проблему секретів протікання в
tfstate

6

Якщо ви перебуваєте на 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 відповідно до кращих практик.


Це дуже прив’язане до служб AWS, про що це питання не згадується і не є справді відповіддю щодо інфраструктури приміщення чи будь-якої іншої хмари.
Тенсібай

@tensibai, ти прав. Оригінальне запитання не дає достатньої інформації для визначення операційної платформи для того, щоб дати найкращу рекомендацію. Кожна платформа буде відрізнятися залежно від можливостей платформи. Користувачі на базі або бареметалі можуть скористатися комбінацією Vault і Terraform Enterprise. Обсяг реалізації цього буде набагато, значно більшим. :)
Ерік Остерман

Я вже використовую AWS Secrets Manager і не хочу використовувати камеру та магазин параметрів. Чи можливо це те ж саме зробити і з менеджером секретів?
red888


2

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


2
до тих, хто прихильнився, поясніть, будь ласка, чому.
jottr
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.