この記事で分かること
- Principalについて
はじめに
AssumeRole基礎についての続きとなります。AssumeRoleは「借りる側」と「貸す側」があるためややこしくなると前回の記事で触れましたが、今回は「貸す側」について焦点を当てたいと思います。
前回の記事は以下をご覧ください。
AssumeRoleについて(おさらい)
AssumeRoleはSTS(Security Token Service)も絡めて流れを説明すると以下のようになります。
①ロールAの認証情報要求。図ではロールAに直接リクエストを送っているように見えますがこれはイメージ図です。厳密にはstsエンドポイントへリクエストが送信され、そこから先はAWSがよしなにコントロールしてくれます。
②認証情報を受け取ります。
③ロールAに許可されたActionを実行します。図ではs3 lsコマンドを実行としていますが、コマンド発行時に認証情報を付加する形でコマンドを実行しています。認証情報は、環境変数として登録しておくことでコマンド内で明示的に認証情報を付加する必要はありません。
上記の説明に間違いはないのですが、となると・・・
STSの権限を持っているユーザ最強じゃん！
となりませんか？なぜなら、STSの権限を持っていればどんなロールであっても借用できてしまいますよね？が、そんなわけはないのです。どんなロールに対しても借用要求はコマンド的にはできますが実際には貸し出してはくれません。その制御が「Principal」です。
Principal
このPrincipalも辞書を引くと「主役」「主な」「第一」「社長」・・・等々が列挙されます。が、Assumeと同じでどれもしっくりこないです。結論から言うと「信頼」とか「信頼関係」と覚えてください。(学校の単語試験では×になりますが)
正面からの説明としては、リソースへのリクエスト/アクセスする主体(＝principal)のことであり、上図だとユーザAとなりますが、ややこしいですよね？実務においては「信頼関係を結ぶためプリンシパルを設定」といった会話で十分に伝わります。信頼関係を結ぶための設定値くらいの感覚で大丈夫です。
そして信頼関係を結ぶためには「貸す側」の制御が必要になります。銀行にお金を借りるとき銀行は貸す側ですが、厳正なチェックを経てお金を借りることができますよね？このチェックに相当するのがPrincipalです。つまり、ロール側(＝貸す側)に設定するものとなります。
以上を踏まえて、AssumeRoleの説明にPrincipalを加えると、①と②の間で「stsの受入許可するPrincipal」の精査が入ります。
よくよく考えてみれば「貸す側」で精査が入るのは当たり前ですが、よく分からない英単語に戸惑ったのを今でも覚えています。また、Principalの対象としては、例のようなユーザの他に、ロールやサービス、アカウント、など様々なリソースに対し信頼設定できます。
さいごに
AssumeRoleの基礎について記述しました。AssumeRoleはロールを「借りる側」と「貸す側」があるためややこしくなります。今回は「貸す側」について記事にしました。「貸す側」から見て誰を(何を)信頼するか を設定するのがPrincipalです。