.tfおよび.tfstateで秘密を管理するにはどうすればよいですか?


46

Terraform MySQLプロバイダーを使用して、mysqlユーザーのリストを保持し、新しいテスト環境を作成するのに便利です。ファイルの両方平文でのMySQLのパスワードを保存するように見えます。.tf.tfstate

.tfについて:

私の理解では、.tfファイルはリビジョン管理に存在し、チームによって維持されています。秘密が存在する場合、その慣行はどのように異なります.tfか?これらの値をまったく暗号化することは可能ですか?

.tfstateについて:

.tfstateTerraform applyを実行した後、どこかに安全に保存できますが、このユースケースではまったく保存しない方が望ましいでしょうか。

回答:


22

Terraform 、呼び出し中に変数を持つ追加ファイルを追加することをサポートしています。

ドキュメント:https : //www.terraform.io/intro/getting-started/variables.html#from-a-file

この機能を使用してsecrets.tfvars、Terraformの呼び出しごとにファイルを提供しています。また、スクリプトを使用してコマンドをラップし、コマンドの呼び出しに一貫性を持たせ、すべてのチームメンバーが同じ間違いをしなくて済むようにします。ラッパーは.tfstate、実行前にS3と同期し.tfstate、最後にS3にプッシュバックします。また、Consulに保存された状態で同じことをしている人もいます。2人が同時にTerraformを起動できないように、consulに一種のセマフォを追加します。

variables.tfファイルにデフォルト値を設定しない場合、ユーザーに値の入力を強制します。手動で入力するか、-var-file上記のようなコマンドオプションを使用して入力できます。シークレットにデフォルトを設定しないことは、シークレットの変更を必要とする変更を実施する良い方法です。

secrets.tfvarsファイルには、バージョンコントロールに格納されていない秘密を持つファイルの1へのシンボリックリンクです。私たちはそうのような、環境ごとに、いくつか持っているsecrets-prod.tfvarssecrets-dev.tfvarssecrets-stg.tfvars、など...

さらに良い方法は、Vaultのデータまたはシークレットを共有する他の方法に基づいて、ラッパースクリプト中にこれらのシークレットファイルを生成することです。現在、シークレットの形式が変更されたとき、またはシークレット自体が変更されたときから、バージョン管理チャネルの外部のチームにそれを伝える必要があります。しかし、秘密はめったに変わりません。



8

テラフォームが秘密を処理するのを避けます。上記で指摘したように、varファイル「secrtes.tfvars」によってシークレットを注入したとしても、これらのシークレットはテラフォーム(リモート)状態で保存されます。

S3認証などを使用してリモート状態ファイルを保護するか、ローカル状態ファイルをgitignoreできますが、この種類の保護に依存しないことにしました。


2
また、github.com / hashicorp / terraform / issues / 516をチェックして、tfstateが秘密を漏らしているという問題を追跡します-jottr
19:34

6

AWSを使用している場合は、AW​​SブログのSegment.ioによる「秘密を管理する正しい方法」ご覧ください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

次に、terraformを呼び出すときにこれらの秘密を使用します。

chamber exec db -- terraform plan

これは、と呼ばれる変数をHCLコードで定義していることを前提DB_USERDB_PASSしています。

たとえば、これを variables.tf

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

注: chamber環境変数は常に大文字でエクスポートされます

terraform-aws-kms-keyKMSキーのプロビジョニングを簡単にするために呼び出されるterraformモジュールを提供します。chamber複数の名前空間で使用する方法の例と、テラフォームでチャンバーを使用して秘密を管理する方法の例を含む詳細なドキュメントをご覧ください。チャンバーの依存関係をプロビジョニングするための完全なリファレンス例を参照してください。

に関しては.tfstate、状態ファイル内のプレーンテキストの秘密の存在について本当に良い点を持ち出します。これを回避する方法は本当にありません。terraformが変更を計算して計画を作成するには、「前」と「後」の状態を知る必要があります。このため、暗号化されたS3バケットと必須のバージョン管理を使用することをお勧めします。terraform-aws-tfstate-backendモジュールを使用して、ベストプラクティスに従ってバケットとDynamoDBロックテーブルをプロビジョニングします。


これは、AWSサービスに強く結びついていますが、この質問には言及されておらず、オンプレミスインフラストラクチャやその他のクラウドに対する答えではありません。
テンシバイ

@tensibai、あなたは正しいです。元の質問では、最適な推奨を行うためにオペレーティングプラットフォームを確認するのに十分な情報が提供されていません。すべてのプラットフォームは、プラットフォームの機能に応じて異なります。premまたはbaremetalのユーザーは、VaultとTerraform Enterpriseの組み合わせの使用を検討できます。それを実装する範囲ははるかに大きくなります。:)
エリックオスターマン

既にAWS Secrets Managerを使用していますが、ChamberとParameter Storeを使用したくありません。Secrets Managerでも同じことを行うことは可能ですか?
red888


2

いくつかの異なる方法を検討しましたが、Vaultのようなより大きなものを実装する前に、アドホックなことをするためにgit-cryptが特に好きでした。


2
ダウン投票した人に、その理由を説明してください。
-jottr
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.