今日やったこと

  • IAMロールを「引き受ける」とはどういう意味なのかを整理した
  • IAMロールは、IAMユーザーのように固定のパスワードやアクセスキーを持たないことを確認した
  • IAMロールを引き受けると、一時的な認証情報が発行されることを確認した
  • AssumeRole という操作の位置づけを確認した
  • aws sts get-caller-identity の Arn に assumed-role が出てくるケースを整理した

学んだこと

IAMロールは「直接ログインするユーザー」ではない

前回、AWS には主に以下のような認証主体があることを整理した。

- rootユーザー
- IAMユーザー
- IAMロール

このうち IAMロールは、IAMユーザーのように直接ログインするためのユーザーではない。

IAMユーザーは、以下のような認証情報を持つことができる。

- マネジメントコンソール用のパスワード
- AWS CLI / SDK 用のアクセスキー

一方で、IAMロール自体は固定のパスワードや長期アクセスキーを持たない。

IAMロールは、必要なときに誰かが一時的に引き受けて使う権限セットとして理解するとよさそう。

IAMロールを引き受けるとは

IAMロールを引き受けるとは、ざっくり言うと、

特定のIAMロールに紐づいた権限を、一時的な認証情報として使える状態にすること

だと理解した。

英語では AssumeRole と呼ばれる。

assume は「引き受ける」「担う」のような意味なので、AWS では IAMロールを使うことを「ロールを引き受ける」と表現する。

IAMロールを引き受けると、そのロールに紐づいた権限を持つ一時的な認証情報が発行される。

AWS のドキュメントでも、ロールを引き受けると、そのロールセッション用の一時的なセキュリティ認証情報が提供されると説明されている。

一時的な認証情報とは

IAMロールを引き受けると、AWS STS によって一時的な認証情報が発行される。

STS は AWS Security Token Service の略。

AssumeRole によって発行される一時的な認証情報には、主に以下が含まれる。

- Access key ID
- Secret access key
- Session token

従来のアクセスキー方式では、Access key ID と Secret access key を長期的に保存して使うことが多い。

一方、IAMロールを引き受けて得られる認証情報には有効期限がある。

有効期限が切れると、その認証情報は使えなくなる。

そのため、長期アクセスキーを配布するよりも、一時的な認証情報を使う方が安全に扱いやすい。

AssumeRole の流れ

IAMロールを引き受ける流れを単純化すると、以下のようになる。

1. ある認証主体が AWS に対して AssumeRole を要求する
2. AWS STS が、その認証主体がロールを引き受けてよいか確認する
3. 許可されていれば、一時的な認証情報を発行する
4. AWS CLI や SDK は、その一時的な認証情報を使って AWS API を呼び出す

図にすると、以下のようなイメージ。

IAMユーザー / AWSサービス / 別アカウント
        |
        | AssumeRole
        v
      IAMロール
        |
        | 一時的な認証情報
        v
 AWS API を呼び出す

IAMロールを引き受ける主体は、人間だけではない。

たとえば、以下のようなものが IAMロールを引き受ける。

- IAMユーザー
- 別のIAMロール
- EC2
- Lambda
- ECSタスク
- 別のAWSアカウント

EC2 に IAMロールを付ける例

分かりやすい例は EC2。

EC2 インスタンスから S3 にアクセスしたい場合、アクセスキーを EC2 内のファイルに保存する方法も一応考えられる。

しかし、それだとアクセスキーが漏えいしたときのリスクが大きい。

そこで、EC2 に IAMロールを付与する。

EC2 インスタンス
  ↓
付与された IAMロールを使う
  ↓
一時的な認証情報を取得する
  ↓
S3 にアクセスする

この構成にすると、EC2 の中に長期アクセスキーを置かなくても AWS API を呼び出せる。

AWS では、EC2 や Lambda などのAWSサービスから他のAWSリソースへアクセスする場合、IAMロールを使う構成が基本になる。

get-caller-identity で確認する

IAMロールを引き受けているかどうかは、aws sts get-caller-identity で確認できる。

aws sts get-caller-identity \
  --profile reotech-dev

IAMユーザーとして操作している場合、Arn は以下のような形式になる。

arn:aws:iam::123456789012:user/example-user

IAMロールを引き受けている場合、Arn は以下のような形式になる。

arn:aws:sts::123456789012:assumed-role/example-role/example-session

assumed-role が含まれていれば、IAMロールを引き受けている状態だと分かる。

前回整理した rootユーザー、IAMユーザー、IAMロールの違いと合わせると、Arn の見方も少し理解しやすくなる。

IAMロールには2つの観点がある

IAMロールを理解するときは、以下の2つを分けて考えるとよさそう。

1. 誰がそのロールを引き受けてよいか
2. そのロールを引き受けたあと、何ができるか

1つ目は、信頼ポリシーで決まる。

誰がこのロールを引き受けてよいか

という設定。

2つ目は、権限ポリシーで決まる。

このロールを引き受けたあと、どのAWSリソースに何ができるか

という設定。

つまり IAMロールには、

- 誰に使わせるか
- 使ったあと何を許可するか

という2つの観点がある。

ここが IAMロールの理解で重要そう。

IAMロールとアクセスキーの違い

IAMユーザーのアクセスキーと、IAMロールを引き受けて得られる一時的な認証情報の違いを整理すると、以下のようになる。

種類 認証情報 有効期限 主な使い方
IAMユーザーのアクセスキー 長期アクセスキー 基本的に無効化・削除するまで有効 CLI / SDK から直接使う
IAMロールの一時的な認証情報 Access key / Secret key / Session token 有効期限あり AssumeRole 後に一時的に使う

IAMロールを使う場合も、内部的には Access key ID や Secret access key のような値は発行される。

ただし、それは長期的に保存して使うものではなく、期限付きの一時的な認証情報として扱う。

ここが重要。

まとめ

IAMロールを引き受けるとは、

IAMロールに紐づいた権限を、一時的な認証情報として使える状態にすること

だと理解した。

IAMロールそのものには、固定のパスワードや長期アクセスキーはない。

代わりに、AWS STS の AssumeRole によって一時的な認証情報が発行される。

その一時的な認証情報を使って、AWS CLI や SDK が AWS API を呼び出す。

AWS の権限管理では、長期アクセスキーを直接配布するよりも、IAMロールを使って一時的な権限を渡す設計が重要になりそう。

あいまいなこと

  • 信頼ポリシーと権限ポリシーの具体的な書き方
  • EC2 に IAMロールを付けたとき、内部的にどのように一時的な認証情報が取得されるのか
  • aws sts assume-role を手動で実行するケース
  • IAM Identity Center を使う場合、どのように IAMロールを引き受けているのか
  • aws login や aws sso login と AssumeRole の関係

次にやること

  • IAMロールと IAMポリシーの違いを整理する
  • 信頼ポリシーと権限ポリシーの違いを整理する
  • aws sts assume-role を手動で実行する方法を確認する
  • IAM Identity Center とは何かを確認する
  • aws login と aws sso login の違いを整理する