Terraformを使用して1台のホストから複数のAWSアカウントへリソースを作成する際、 認証情報の管理方法に迷うことが多いと思います。以下に、簡単な3つの方法を解説します。
1. 環境変数を使用する方法
AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYのような環境変数をセットする方法です。 下記のように、セッションごとに認証情報をセットできます。
export AWS_ACCESS_KEY_ID="access_key_id" export AWS_SECRET_ACCESS_KEY="secret_access_key" export AWS_DEFAULT_REGION="ap-northeast-1"
- メリット
- 設定が簡単で、素早いテストやデプロイに便利です。
- デメリット
2. AWS CLIプロファイルを利用する方法
~/.aws/credentials ファイルに複数のAWSアカウントの認証情報を格納します。 例えば、2つの異なるアカウントの認証情報は以下のように設定できます。
- ~/.aws/credentials
[default] aws_access_key_id = access-key-id aws_secret_access_key = secret-access-key [dev] aws_access_key_id = dev-access-key-id aws_secret_access_key = dev-secret-access-key
- provider.tf
provider "aws" { profile = "dev" region = "ap-northeast-1" }
- メリット
- デメリット
- credentialsファイルに全てのキーが記載されるので実行ホストに対するアクセスやファイルの参照権限の考慮が必要。
3. Assume Roleを使用する方法
ソースアカウントで認証した後、ターゲットアカウントのロールをassumeできます。
1. ターゲットアカウントでAssume Roleを許可するIAMロールを作成し、Terraformの実行に必要なポリシーを付与します。
2. ソースアカウントの実行ユーザがターゲットアカウントのIAMロールをassumeできるよう設定します。
3. ソースアカウントの認証情報を前述の方法で実行環境から利用可能にします。
4. tfファイルでproviderブロック内またはリソースレベルでassume_roleを指定します。
- provider.tf
provider "aws" { region = "us-west-2" assume_role { role_arn = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME" } }
- メリット
- ターゲットアカウントのアクセスキーとシークレットキーを共有する必要ない。
- Assume Roleを利用するのでイベントの追跡、セッション期限が容易に設定可能。
- ソースアカウントの実行ユーザを最小限の権限にできる。
- デメリット
- 他の方法と比べると初期設定がやや複雑。
上記以外にもAWS SSOやTerraform Cloudを使うなど、たくさんの方法があると思います。
用途やセキュリティポリシーに応じて最適な認証手法を選択していきましょう。