AWSのIAMロールの切り替えをやってみたのでその記録です。
やりたいこと
①EC2のフルアクセス権限があるIAMユーザーでEC2が見れること、S3が見れないことを確認
②S3のフルアクセス権限があるロールにスイッチロール
③EC2が見れないこと、S3が見れることを確認
切り替え先IAMロール作成
「信頼されたエンティティタイプ」でアカウントを選択します。
ポリシーとしてAmazonS3FullAccessを選択します。
任意のロール名を入力してロールを作成します。
ここでは信頼ポリシーは以下のようになっています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "【アカウントID】"
},
"Condition": {}
}
]
}
Resourceは特に指定がないので、このロールをかぶったアカウントはどのS3バケットに対してもS3フルアクセスが与えられます。
IAMユーザー作成
作業を簡易化するために、今回はカスタムパスワードを使い、パスワード再作成も不要なようにしておきます。
今回、IAMユーザーには2つの権限を与えます。
一つはEC2のフルアクセス権限です。もう一つはこの場で「ポリシーの作成」を押してポリシーを新たに作成します。
ロールの切り替えを行うには、STSサービスのAssumeRole権限が必要です。
これは、通常のIAMロールを作成するときに信頼ポリシーにも記載のある権限です。IAMロールはEC2やLambdaなどのリソースにかぶせることで権限を与えることができますが、今回はそれがアカウントに対してかぶせられるというイメージです。
そのためこのIAMユーザーは、アカウント
サービスで「STS」を選択し、「書き込み」の中から「AssumeRole」を選択します。
リソースの「特定」を選択し、「ARNを追加」をクリックします。
先ほど作成した、S3フルアクセス権限をもつIAMロールの名前を上の段に入力することで、リソースARNが指定されます。入力したら「ARNを追加」をクリックします。
ポリシーの作成が完了したら、元のユーザー作成画面に戻り、ただいま作成したポリシーを選択すればIAMユーザー作成完了です。
作成されたポリシーの中身を見てみましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::【アカウントID】:role/AmazonS3FullAccessRole"
}
]
}
S3フルアクセス権限をもつロールに対して、AssumeRoleできるポリシーとなっていることがわかります。Principalは、今回の場合はEC2のフルアクセス権限をもつIAMユーザーということになります。
動作確認~ロール切り替え前
作成したIAMユーザーでログインし、EC2サービスダッシュボードへ遷移すると、インスタンス数などのリソースを確認することができます。
一方、S3サービス画面では権限不足によりバケットを確認する事が出来ません。
動作確認~ロール切り替え
画面右上のIAMユーザー名@アカウント名部分をクリックし、「ロールの切り替え」をクリックします。
アカウントID、S3フルアクセス権限をもつロール名を入力し、「Switch Role」をクリックします。
動作確認~ロール切り替え後
先ほどまで確認できていたEC2のリソース部分が、権限不足によるAPIエラーが発生して確認できないことがわかります。
S3サービス画面に移動すると、S3バケットを問題なく確認できることがわかります。
まとめ
IAMロールというものがどういうものか、IAMロールでAssumeRoleがどう使われているかがわかっていると、スイッチロールもより理解しやすいですね。
今回は1アカウント内での切り替えでしたが、実際の現場ではマルチアカウントで限定的な権限を一時的に与えたいときに使えそうです。