Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@Ryku

AWS My First Setup - 自分流初期設定の忘備録

Last updated at Posted at 2023-01-05

目的

  • コンソールで作業するための前準備を完了させる
  • Terraformで作業するための前準備を完了させる

の2点です。アカウント開設直後はrootユーザーのみですが、rootユーザーで作業したくないですね。そのためアカウント開設から作業できる状態にするまでの下準備が結構あるのですが、毎回忘れがちなので記録しておきます。

Assume Roleを活用する

安全な作業（デプロイ）に向けて、AssumeRoleを活用します。AssumeRoleの概念は以下の動画がわかりやすいです。

動画では

  • スイッチロール用ユーザー→デプロイRole（Cloud Formationでデプロイするポリシーのみ）→CloudFormation Role（デプロイのためのポリシー全てを持つ）

の順で権限が移っていきますが、Terrafromの場合は

  • スイッチロール用ユーザー→デプロイRole（デプロイのためのポリシー全てを持つ）

の順で権限移動で十分かと思います。

必要なエンティティ

Assume Roleを活用するためにスイッチロール用のIAMユーザー、デプロイ用のIAMロールを作成します。

  • スイッチロール用のIAMユーザー
    • デプロイ用の権限を持つロールを引き受ける器です。
    • アタッチするポリシーはAssumeRoleするためのポリシーのみでOKです。
  • デプロイの権限を持つIAMロール
    • デプロイ用のIAMロール。信頼するエンティティにスイッチロール用のIAMユーザーを指定します。
    • AdministratorAccessポリシーを付与することで、ほとんどのリソース操作ができるようになります。
    • 今後の作業（デプロイ）でAWSのリソースを操作する際はこちらのロールをAssumeRoleしたIAMユーザーを使用します。

スイッチロール用IAMユーザーと、デプロイ用IAMロールの作成

ここは仕方がないのでrootユーザーでやるしかないです。基本的にはこの作業のみにrootユーザーを使用します。

rootユーザーのベストプラクティス

rootユーザーでは最初のIAMユーザーの作成、請求情報の変更など、rootユーザーでしかできないことをするときのみ使用して、それ以外はIAMユーザーを使用しての開発が推奨されています。安全なやり方を追求するのであれば、rootユーザーのアクセスキーは破棄してしまいましょう。CLIから作業をする場合はアクセスキーが必要になりますが、UIからのみ作業することにしておけばアクセスキーを持つ必要がなくなるためアクセスキーを削除できます。そのため管理する必要のあるものはログインパスワードのみで良くなります。自分は初回のIAMユーザー、IAMロール作成のみrootユーザーからUI操作で設定して、以降はほぼ使いません。
rootユーザーのアクセスキーを消すと、以下のようにAWSからセキュリティに関するレコメンデーションの項目をクリアすることができます。（MFAも設定推奨です）

スクリーンショット 2022-12-25 14.04.52.png

スイッチ用IAMユーザーの作成

スクリーンショット 2023-01-06 1.58.36.png

上記のように作成します。ChangePasswordポリシーは勝手についてきます。

デプロイ用IAMロールの作成

最初の信頼されたエンティティ設定で、カスタム信頼ポリシーを選択後、以下のように記入する。
その後、許可を追加の設定で、AdministratorAccessポリシーを追加します。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Effect": "Allow",
			"Principal": {
			    "AWS": "arn:aws:iam::<account_id>:user/<switch_iam_user_name>"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

スイッチ用IAMユーザーがデプロイ用IAMロールを引き受けるためのポリシーの作成

ポリシーの作成から以下を記入して作成します。作成したポリシーをスイッチ用IAMユーザーにアタッチします。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<account_id>:role/<deploy_iam_role_name>"
  }
}

ロールの切り替えが可能になる

作成したスイッチ用のIAMユーザーでログイン後、コンソール画面右上のロールを切り替えをクリックで以下の設定画面になります。ロールに先ほど作成したデプロイ用IAMロールの名前を入力すればスイッチができるようになっているはずです。
これ以降コンソールで作業する必要が出てきた場合はこのロールで作業します。

スクリーンショット 2023-01-05 23.20.49.png

Terraformでの使用方法

ここまで作業した場合、AWSのリソースにアクセスできる認証情報は

  • rootユーザーのログインパスワード
  • スイッチロール用ユーザーのログインパスワード
  • スイッチロール用ユーザーのシークレットアクセスキー

の3つです。

Terraformで使用するのは、スイッチロール用ユーザーのシークレットアクセスキーになります。
普通に使用しようとすると、~/.aws/credentialsに保存してterraform実行時に参照してもらうことになりますが、もちろんそのまま参照するだけではスイッチロール用ユーザーは何の権限も持っていないため何もできません。
そこで、今回はAssumeRoleとaws-vaultを組み合わせて実行環境を構築します。

aws-vaultではアクセスキーをKeyChainに保存する仕組みになっているため、自分のストレージ内の~/.aws/credentials保存するよりもいくぶん安全に運用ができます。KeyChainではAppleさんがかなり強固な暗号化技術によってキーを保存＆管理しているようです。

aws-vaultの使用方法

インストール

brew cask install aws-vault

スイッチロール用ユーザーのシークレットアクセスキーを登録する。

$ aws-vault add UHOUHO
Enter Access Key ID: <switch_role_user_access_key_id>
Enter Secret Access Key: <switch_role_user_secret_access_key>

このままだと何も実行できないため、以下のようにしてデプロイ用IAMロールを指定したprofileを~/.aws/configに記載します。

~/.aws/config
[profile UHOUHOassumerole]
source_profile = UHOUHO
role_arn = arn:aws:iam::<account_id>:role/<deploy_iam_role_name>

以上の設定で完了です。
aws-vault exec <profile> --の後に実行したいコマンドを入力すると、一時的なAWSの認証情報が環境変数として渡された状態でコマンドが実行されます。例えば以下のコマンドを打つとそのことが確認できると思います。

$ aws-vault exec <profile> -- env | grep '^AWS'
AWS_VAULT=hogehoge
AWS_DEFAULT_REGION=ap-northeast-1
AWS_REGION=ap-northeast-1
AWS_ACCESS_KEY_ID=uhouho
~~~~~~

そのため、以下コマンドを実行することで、デプロイ用IAMロールにスイッチしたIAMユーザーからTerraformを実行できるようになります。

aws-vault exec <profile_name> -- terraform plan/apply

このaws-vaultで発行される認証情報の有効期限は1時間です。
あまりないとは思いますが、plan/applyに1時間以上かかる場合は失敗してしまいます。

aws-vaultで発行される認証情報の有効期限を伸ばす

AWSでのスイッチロール（AssumeRole）により取得できる一時的な認証情報の有効期限はデフォルトで1時間となっているため、1時間以上のプロセスを実行することができません。
aws-vault exec時に-d/--durationオプションで一応有効期限（Time-To-Live）を設定することはできますが、2h以上を指定しようとすると↓のようなエラーが出てしまいます。

$ aws-vault exec <profile> -d 2h -- aws s3 ls                                                                                                           
aws-vault: error: exec: Failed to get credentials for <profile>: operation error STS: AssumeRole, https response error StatusCode: 400, RequestID: <any_requestID>, api error ValidationError: The requested DurationSeconds exceeds the MaxSessionDuration set for this role.

しかし、これはAWS CLIのiam role updateコマンドで延長させることができます。

以下コマンドを打ってみましょう。すると、デフォルトで1時間に設定されていることが確認できます。

$ aws-vault exec <profile> -- aws iam get-role --role-name <deploy_iam_role_name> --query Role.MaxSessionDuration
3600

これをaws iam updateで3時間に延長してみます。このコマンドを実行した後に再度↑のコマンドを打つと10800と出力され、変更されたことが確認できます。

最大で12時間まで延長が可能ですが、それと同時に認証情報が漏れた際のリスクも増えてしまうため、必要な分だけ延長するように留意しましょう。

$ aws-vault exec <profile> -- aws iam update-role --role-name <deploy_iam_role_name> --max-session-duration $((60*60*3))

以上の操作を行うと、-d/--durationオプションで1時間よりも長時間の有効期限を設定することができます。

$ aws-vault exec <profile> -d 2h -- aws s3 ls                                                                                                    
20XX-XX-XX HH:mm:ss my-bucket
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?