IAMロールからIAMロールへ。「ロールの連鎖（Role Chaining）」を試して学んだこと

はじめに
IAMロールの連鎖(Role Chaining)とは？
実践！検証環境の構築
AWS CloudShellで連鎖を実行してみる
- 1. まずはUserからRole-Aへ
- 2. Role-A から Role-B へ（これが連鎖！）
おわりに

はじめに

皆さんは IAMロール（IAM Role）、使いこなせていますか？私は学習を始めた頃、「IAMユーザーと何が違うの？」というレベルで混乱していましたが、最近ようやく「帽子（役割）を被り替えるイメージ」という理解で落ち着いてきました。しかし、学習を進めると「あるIAMロールから、さらに別のIAMロールにスイッチする」という構成が出てきます。これを「IAMロールの連鎖（Role Chaining）」と呼びます。

「え、一回着替えたのに、その上からまた着替えるの…？重ね着？」

そんな疑問を持ちつつ、今回はこの仕組みを理解するために、あえて単一のAWSアカウント内でロールをリレーする構成を作って検証してみましたので備忘録としてまとめます。

IAMロールの連鎖(Role Chaining)とは？

通常、IAMロールを使う場面というと、IAMユーザーが特定のロールにスイッチする（User -> Role A）パターンが一般的です。しかし「ロールの連鎖」は、以下のようにロールが別のロールを引き受ける状態を指します。

User -> (Switch) -> Role A -> (Switch) -> Role B

今回は仕組みを理解するため、1つのアカウント内でこのリレーを再現します。

公式ドキュメント docs.aws.amazon.com

実践！検証環境の構築

では、実際に設定していきます。今回はAWSマネジメントコンソール上の CloudShell（ブラウザで使えるターミナル）を使って検証します。

登場人物一覧 - User (自分)：操作するIAMユーザー - Role-A (中間)：最初にスイッチするロール - Role-B (ゴール)：Role-Aからしかスイッチできないロール

step1: 中継地点「Role-A」の作成

まず中継地点となるロールを作成します。

IAMコンソールで「ロールを作成」をクリック。
信頼されたエンティティタイプ: AWSアカウント「このアカウント」を選択。
許可ポリシー: いったん何も設定せずに「次へ」。
ロール名: Role-A と入力して作成。

step2: ゴール地点[Role-B]の作成

次に、最終的になりたいロールを作成します。ここで「Role-A からしかスイッチできない」という制限（信頼ポリシー）をかけます。

「ロールを作成」をクリック。
信頼されたエンティティタイプ: 「カスタム信頼ポリシー」を選択。
エディタに以下のJSONを入力します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "＜Role-A の ARN＞"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

許可ポリシー: 付与したい許可ポリシーを付与。（今回は検証用なのでAdministratorAccessを付与しています）
ロール名: Role-B と入力して作成。

step3: Role-A に「Role-Bへ行く許可」を与える

最後に、Role-A に「Role-B にスイッチしてもいいよ」という許可を与えます。

IAMコンソールで再度 Role-A を開きます。
「許可」タブ → 「許可を追加」 → 「インラインポリシーを作成」。
JSONエディタを選択し、以下を入力します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "＜Role-BのARN＞"
    }
  ]
}

ポリシー名（例: AllowSwitchToRoleB）を入力して作成。

AWS CloudShellで連鎖を実行してみる

ロールの連鎖の下準備が完了したので早速試してみましょう。

1. まずはUserからRole-Aへ

CloudShellを起動し、以下のコマンドを実行します。 jq コマンドを使って、取得した一時クレデンシャルを環境変数にセットしています。

# アカウントIDを変数にセット（自身のIDに書き換えてください）
ACCOUNT_ID="123456789012"

# 1. Role-A に切り替え
temp_role=$(aws sts assume-role --role-arn "arn:aws:iam::${ACCOUNT_ID}:role/Role-A" --role-session-name Session-A)

# 2. 認証情報を環境変数にセット
export AWS_ACCESS_KEY_ID=$(echo $temp_role | jq -r .Credentials.AccessKeyId)
export AWS_SECRET_ACCESS_KEY=$(echo $temp_role | jq -r .Credentials.SecretAccessKey)
export AWS_SESSION_TOKEN=$(echo $temp_role | jq -r .Credentials.SessionToken)

# 3. 確認
aws sts get-caller-identity

▼ 実行結果 Arnの末尾が assumed-role/Role-A/Session-A になりました。第一段階のロール切り替えができているのが確認できます。

2. Role-A から Role-B へ（これが連鎖！）

今、私は Role-A に切り替えができている状態です。この状態でさらに Role-B へのスイッチを行ってみます。

# 1. Role-B に切り替え（Role-Aの権限を使用して切り替え）
target_role=$(aws sts assume-role --role-arn "arn:aws:iam::${ACCOUNT_ID}:role/Role-B" --role-session-name Session-B)

# 2. 認証情報を上書き
export AWS_ACCESS_KEY_ID=$(echo $target_role | jq -r .Credentials.AccessKeyId)
export AWS_SECRET_ACCESS_KEY=$(echo $target_role | jq -r .Credentials.SecretAccessKey)
export AWS_SESSION_TOKEN=$(echo $target_role | jq -r .Credentials.SessionToken)

# 3. 確認
aws sts get-caller-identity

▼ 実行結果 Arnが assumed-role/Role-B/Session-B に変わりました。これで「User → Role-A → Role-B」という連鎖ができました。