↓の本の「6章 シークレットを管理する」のメモを残します。
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/1d6ee267.a32b0df7.1d6ee268.77289141/?me_id=1213310&item_id=21090768&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F0522%2F9784814400522_1_3.jpg%3F_ex%3D300x300&s=300x300&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
前章のメモ
シークレットとは？
機密情報のこと。
DBのパスワード、APIキー、SSHキー、AWSの認証情報など。
シークレット管理の基本
シークレット管理の大原則は
プレーンテキストのシークレットをバージョン管理システムに保存しない
理由は、比較的容易に閲覧でき、誰がいつ情報にアクセスしたのかを把握できないから
AWSの認証情報をGitHubのpublicなリポジトリにハードコードしてしまい、
その情報を悪用され、後日AWSから多額の請求がきてしまうなんて話もあります。
シークレットの取り扱いには十分に注意しましょう
シークレット管理ツールとTerraform
プロバイダの認証情報
例えば、AWSへデプロイするときには認証を突破する必要があります。
この認証情報をどのように管理するのがよいでしょうか？？
Terraformでデプロイを実行するのが人かマシンかで分けて考えてみます
人がTerraformを使ってデプロイする
ローカルPCでterraform applyコマンドを実行する場合です。
- 汎用的なシークレットマネージャに保存し、環境変数に設定する
- aws-valut のような各プロバイダ専用のシークレットマネージャを使用する
マシンがTerraformを使ってデプロイする
マシン＝GitHub ActionsやCircleCI、Jenkinsサーバなどのこと。
- CIサービスの環境変数を使用する
- 認証情報を手動で管理する必要があり大変
- CIサーバとしてのEC2インスタンスのプロファイルにIAMロールを設定する。
- 手動で認証情報を管理する必要がない
- OIDCを使う
- CIサービスとクラウドプロバイダ間の信頼関係を使用するため認証情報の管理がない
- OIDCを使用できるGitHubのリポジトリやブランチを絞れるのでセキュア
GitHub ActionsでOIDCを使用したAWSへのCI/CDワークフローの作り方は↓を参考にしてください！
リソースとデータソース
環境変数を使う
Terraformでsensitive=trueの変数を定義し、TF_VARから始まる環境変数を読み込むようにする方法
暗号化されたファイルを使う
暗号化したシークレットをファイルに保存して、バージョン管理システムにアップする方法
具体的には、AWSのKMSで作った暗号鍵でシークレットを暗号化してファイルに保存します。
それをバージョン管理システムにアップし、必要に応じて複合化して使います。
シークレットストアを使う
AWS Secrets ManagerやGoogle Secret Managerなどを使う方法
ステートファイルとプランファイル
ステートファイル＝terraform apply してデプロイした結果
プランファイル＝terraform planの出力結果
これらのファイルにはシークレットが記載されてしまうため、
- ファイルを暗号化できるバックエンドを選ぶ
- バックエンドへアクセスできる人を絞る
ことが必要です
次章のメモ
コメント