-
タグ
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR
クラウドインテグレーションサービス部 吉川です。
昨今、データの管理・制御やデータの局所性の確保、コストの最適化などの理由からマルチクラウドや、Infrastructure as Code(以下、IaC)への関心が高まり、TerraformをIaCツールとして選定する機会が増えてきました。しかし、TerraformでAWS環境を構築する場合、認証情報としてアクセスキーが必要になるため、敷居が高いと思う人も多いのではないでしょうか。
アクセスキーはなるべく使わない方針とする理由の一つに、万が一アクセスキーが漏洩してしまうと、AWS環境へ不正にアクセスされる恐れがあるため、顧客情報の漏洩や高額な利用料を請求されるといったセキュリティリスクがある点が挙げられます。また、アクセスキーを払い出すと、キーのローテーションや、漏洩の検知、キーを削除する仕組みなどを作りこむ必要があるため、時間やコスト、人的リソース確保の観点から、なかなか対応が難しいと思います。
実はラックのAWS検証環境も原則アクセスキーを払い出さない方針にしています。本記事では、Terraform Cloudの認証情報にアクセスキーを払い出すのではなく、AWSのサービスに対して操作権限を付与する「IAMロール」を使用してAWSリソースを構築する方法を紹介します。
AWS Security Token Serviceを使用してIAMロールを引き受けることで、一時的かつ動的なセキュリティ認証情報を使用でき、アクセスキーの管理・運用から解放されることが利点になります。
OpenID Connect IDプロバイダの作成
OpenID Connect IDプロバイダの作成手順を説明します。
※ IAM権限があるIAMユーザで作業をしてください。
AWSマネジメントコンソールにサインインし、IAMサービス画面を開きます。左側メニューから[IDプロバイダ]を選択し、[プロバイダを追加]をクリックします。
1. プロバイダの設定
以下の通り設定します。
プロバイダのタイプは[OpenID Connect]を選択します。
プロバイダのURLは[https://app.terraform.io]を入力します。
[サムプリントを取得]をクリックします。
対象者に[aws.workload.identity]を入力します。
タグは任意で設定し、[プロバイダを追加]をクリックします。
OpenID Connect IDプロバイダが作成されたことを確認します。
2. IAMロールの作成
AWSマネジメントコンソール上部にある[ロールの割り当て]をクリックします。
Terraform Cloud用のIAMロールを新規に作成するために、[新しいロールを作成]を選択し、[次へ]をクリックします。
Audienceに[aws.workload.identity]を入力し、[次のステップ:アクセス権限]をクリックします。
※ ウェブIDとIDプロバイダはデフォルトの状態です。
ロールにアタッチする任意のポリシーを選択します。今回は検証のため[PowerUserAccess]を選択しました。
今回は検証のためアクセス権限の境界の設定は特にせず、[次のステップ:タグ]をクリックします。
※ PowerUserAccessはIAM、Organizations、AWSアカウントの操作以外の権限があります。権限を絞りたいときにアクセス権限の境界を設定します。(保有する権限とアクセス権限の境界で設定した権限が重複した権限のみ許可されます。)
タグは任意で設定し、[次のステップ:確認]をクリックします。
ロール名やアタッチするポリシーなどを確認し、[ロールの作成]をクリックします。
IAMロールが作成されたことを確認します。
信頼ポリシーの編集
TerraformCloudがIAMロールを引き受けられるように信頼ポリシーを編集します。
AWSマネジメントコンソールのIAMサービス画面を開きます。左側メニューからロールを選択し、前手順で作成したロールをクリックします。
[信頼関係]タブを選択し、[信頼ポリシーを編集]をクリックします。
現在設定されているポリシーをすべて削除し、後述しているポリシーに修正します。
[ポリシーを更新]をクリックします。
信頼ポリシーは以下のように設定します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "①arn:aws:iam::【12桁のアカウントID】:oidc-provider/app.terraform.io" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "②app.terraform.io:aud": "③aws.workload.identity", "②app.terraform.io:sub": "organization:④【組織名】:project:⑤【プロジェクト名】:workspace:⑥【ワークスペース名 ※今回はaws_test】:run_phase:⑦*" } } } ] }
各設定値の説明です。
- ①OpenID Connect IDプロバイダのARN
- ②Terraform Cloudのアドレスからhttps://を削除したもの(例:app.terraform.io)
- ③Terraform Cloudの環境変数[TFC_AWS_WORKLOAD_IDENTITY_AUDIENCE]の値
※ 環境変数を定義していない場合は、デフォルトだとaws.workload.identityを設定。
- ④このポリシーを適用するTerraform Cloudの組織名
- ⑤このポリシーを適用するプロジェクト名
- ⑥このポリシーを適用するワークスペース名
- ⑦このポリシーを適用する実行フェーズ(planまたはapply、もしくはアスタリスク)
※ 今回はplanもapplyも同じロールを使用したいので、run_phaseはアスタリスクで設定しています。また、ワイルドカードを使用しない場合は、StringLikeではなく、StringEqualsを使用できます。
各設定値の確認方法です。
AWSマネジメントコンソール→IAMサービス画面→IDプロバイダ→前手順で作成したOpenID Connect IDプロバイダを選択し、①~③の設定値を確認します。
Terraform Cloudにサインインして④~⑥の設定値を確認します。
[信頼関係]タブを選択し、表示されたポリシーが更新されていることを確認します。
以上でOpenID Connect IDプロバイダの設定は完了です。
Terraform Cloudの環境変数設定
Terraform Cloudの環境変数設定手順を説明します。
※ すでにワークスペースがある前提の手順となっています。ワークスペースがない場合は、ワークスペースの作成からお願いします。今回使用しているワークスペースはCLI環境になります。
Terraform Cloudにサインインし、ワークスペースを選択します。左側メニューから[Variables]を選択します。
[+ Add variable]をクリックします。
以下の通り設定します。
Select variable categoryは[Environment variable]を選択します。
Keyには[TFC_AWS_PROVIDER_AUTH]を入力します。
Valueには[true]を入力します。
[Add variable]をクリックします。
Variablesの画面に戻るので、再び[+ Add variable]をクリックします。
以下の通り設定します。
Select variable categoryは[Environment variable]を選択します。
Keyには[TFC_AWS_RUN_ROLE_ARN]を入力します。
Valueには[IAMロールのARN]を入力します。
※ IAMロールのARNは、AWSマネジメントコンソール→IAMサービス画面→ロール→前手順で作成したロールを選択→ARNからコピーしてください。[Add variable]をクリックします。
2種類の環境変数が追加されたことを確認します。以上でTerraform Cloudの環境変数設定は完了です。
動作確認
tfファイルの準備
テスト用のtfファイルを作成します。今回はVPCを作成するコードを用意しました。
※【】部分は各自の環境に読みかえてください。
#組織とワークスペース名の設定 terraform { cloud { organization = "【組織名】" workspaces { name = "【ワークスペース名 ※今回はaws_test】" } } } #リージョンの設定 provider "aws" { region = "ap-northeast-1" } #VPC作成 resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true tags = { Name = "terraformcloud_vpc" } }
VPC作成・削除の動作確認
※ ローカルPCにTerraformがインストールされている前提の手順になっています。
1. VPC作成
Terraform CloudのワークスペースはCLI環境で作成しているので、コマンドプロンプトを使用して動作確認を行います。
コマンドプロンプトで[terraform login]コマンドを実行すると、ブラウザが自動で立ち上がり、トークンの有効期限を求められます。トークンの有効期限を任意の期間で設定し、[Generate token]をクリックします。今回は動作確認なので、有効期限を1時間で設定しています。
ブラウザ上でトークンが払い出されるので、コピーしてコマンドプロンプトに貼り付けます。[Welcome to Terraform Cloud!]の画面が表示されたら、Terraform Cloudを使用することができます。
テスト用のtfファイルを格納しているフォルダに移動し、[terraform init]コマンドを実行します。[Terraform Cloud has been successfully initialized!]と表示されたことを確認します。
[terraform apply]コマンドを実行します。
[Apply complete!]と表示されたことを確認します。
AWSマネジメントコンソールにサインインして、VPCが作成されているか確認します。テスト用のtfファイルで定義したVPCが作成されているのがわかると思います。
2. VPC削除
削除の方も動作確認してみます。
[terraform destroy]コマンドを実行します。
[Apply complete!]と表示されたことを確認します。
AWSマネジメントコンソールを確認すると、VPCが削除されたことがわかります。以上で動作確認は完了です。
最後に
Terraform Cloudの認証情報にIAMロールを使用してAWSリソースを構築することができました。アクセスキーを払い出さなければ、アクセスキーの漏洩は発生しないためセキュリティリスクは低減します。また、キーの管理も必要ないため、キーのローテーションや漏洩を検知する仕組みを作りこむ必要がなく、コスト、人的リソースを削減できます。
セキュリティ面、コスト面それぞれに対し利点のあるIAMロールを使用したAWSリソース構築、検討してみてはいかがでしょうか。
参考資料
- AWSプロバイダによる動的認証情報
Dynamic Credentials with the AWS Provider - Workspaces - Terraform Cloud | Terraform | HashiCorp Developer - OpenID Connect(OIDC) IDプロバイダの作成
Creating OpenID Connect (OIDC) identity providers - AWS Identity and Access Management
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- もっと見る +
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR