この記事で分かること
- AssumeRoleについて
- STSについて
はじめに
AssumeRoleはおそらくですが、かなりのAWS初学者が躓くところだと思います。しかしAssumeRoleを説明している記事はどうしても煩雑な印象を受けます。私自身も書いてみて分かりましたが、わかりやすく伝えるのが難しいです。まずはAssumeRoleの外観を掴んでもらうことをこの記事の目標としたいと思います。
AssumeRoleについて
「Assume」が慣れない英単語で、しかも辞書で調べても「仮定する」「推測する」といった別の意味が筆頭に来る気がします。ですので、まずは「Assume」の和訳を頭に入れるとよいと思います。この場合のAssumeの意味は「引き受ける」です。よって、Roleを引き受ける、というのが直訳になります。
そして、Roleとは「役割」を意味します。開発者、システム管理者、オペレーター、財務管理担当・・・あげればキリがないですが、各役割に対し適切な権限(＝ポリシー)を付与したものをAWSではIAMロールと呼びます。
上記踏まえてAssumeRoleをもう少し直感的に分かりやすく意訳すると「権限を借り受ける」となります。個人的には「借りる」・・つまり、いつかは返却される「一時的なもの」という感覚が重要だと思います。
ここで、以下のユーザAとユーザBを考えます。図の帽子はAWSのIAMロールのアイコンです。
ユーザA：AssumeRoleする権限のみを有する
ユーザB：様々な権限を有する
もちろんユーザBが危険なのですが、その理由としてユーザＢのパスワード漏洩＝様々な権限で不正操作に直結します。ユーザAの場合、パスワードが漏洩してもAssumeRoleしかできず、実質データへのアクセスは不可。もちろん、Assume先のRole名を把握していた場合はAssumeRoleして不正操作はもちろん可能ですが、ユーザBよりハードルが高いのは明らかです。
また、AssumeRoleでは認証情報が一時的に払い出されるのですが、「一時的」が意味するように制限時間が設けられています。つまり(ユーザAのパスワードではなくロールの)認証情報を何らかの方法で取得したとしても永続的に使用はできないため、セキュリティが高まることになります。（後述のSTSにて解説します）
AssumeRoleは、実は要点は上記のみです。しかし借り受けるということは貸し出す側も存在するため、設定を記述するとややこしくなります。資格試験でもAssumeRoleに関する問題は頻出で「借りる側」と「貸す側」を整理して読み解く必要があります。おそらくですが、ここの説明がAssumeRoleに関する記事を煩雑にしているのだろうと思います。
STSについて
STSとは「Security Token Service」の略です。その名の通りセキュリティトークンを生成します。そしてこのセキュリティトークンが認証情報です。
前述のユーザAに付与されている権限：AssumeRoleする権限、について間違ってはいないのですが、この文言だけで覚えてしまうと中間部分が抜けてしまうという感じでしょうか。
トークンを踏まえてAssumeRoleの流れを図にすると以下のようになります。
①ロールAの認証情報要求。図ではロールAに直接リクエストを送っているように見えますがこれはイメージ図です。厳密にはstsエンドポイントへリクエストが送信され、そこから先はAWSがよしなにコントロールしてくれます。
②認証情報を受け取ります。
③ロールAに許可されたActionを実行します。図ではs3 lsコマンドを実行としていますが、コマンド発行時に認証情報を付加する形でコマンドを実行しています。認証情報は、環境変数として登録しておくことでコマンド内で明示的に認証情報を付加する必要はありません。
さいごに
AssumeRoleの基礎について記述しました。AssumeRoleはロールを「借りる側」と「貸す側」があるためややこしくなります。まずは、AssumeRoleの外観を掴めてもらえたら幸いです。