📦

Permission Set は AWS アカウント内で何になるのか

に公開
AWS
Security
IAM
AWS CLI
AWS IAM Identity Center
tech

Permission Set は AWS アカウント内で何になるのか

IAM Identity Center の許可セットを使うと、開発者は AWS アクセスポータルや aws sso login から AWS アカウントに入れます。
ただ、実際に AWS アカウント内で何が作られているのかは、最初は少し見えにくいかもしれません。

この記事では、Permission Set が AWS アカウント内で AWSReservedSSO_* ロールとして扱われる仕組みを整理します。
CloudTrail の assumed-role や、sts get-caller-identity の出力を読むときの前提にもなります。

全体像

Permission Set は IAM Identity Center 側に保存される権限テンプレートです。
その Permission Set を AWS アカウントに割り当てると、対象アカウントの IAM にロールが作成されます。

ユーザーが直接 IAM ユーザーとして AWS アカウントに入るわけではありません。
IAM Identity Center が管理する IAM ロールを、認可されたユーザーが一時的に利用する形です。

AWSReservedSSO_* ロールとは

AWS アカウントの IAM ロール一覧を見ると、次のような名前のロールが見つかることがあります。

AWSReservedSSO_DeveloperReadOnly_1a2b3c4d5e6f7890
AWSReservedSSO_DeveloperPowerUser_0f1e2d3c4b5a6978
AWSReservedSSO_BreakGlassAccess_1234567890abcdef

これは IAM Identity Center が作成・管理するロールです。
名前には、おおむね次の情報が含まれます。

AWSReservedSSO_<PermissionSetName>_<suffix>

<PermissionSetName> は許可セット名に対応します。
末尾の suffix は IAM Identity Center 側で生成される識別子で、通常ユーザーが決めるものではありません。

なぜロールが必要なのか

AWS の各サービスに API を実行するには、最終的に IAM の認可判断が必要です。
IAM Identity Center はユーザーやグループを管理しますが、AWS アカウント内でサービスを操作するときは IAM ロールとして扱われます。

そのため、aws sts get-caller-identity を実行すると、次のような ARN が返ります。

aws sts get-caller-identity --profile dev-readonly

{
  "UserId": "AROAXXXXXXXXXXXXX:user@example.com",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_DeveloperReadOnly_1a2b3c4d5e6f7890/user@example.com"
}

この出力のポイントは、user@example.com が IAM ユーザーとして存在しているわけではないことです。
実際には、AWSReservedSSO_DeveloperReadOnly_... というロールを一時的に引き受けたセッションとして見えています。

アカウント割り当てで何が起きるか

IAM Identity Center でユーザーやグループに AWS アカウントアクセスを割り当てると、次のような流れになります。

  1. IAM Identity Center に Permission Set を作成する
  2. AWS アカウントを選ぶ
  3. ユーザーまたはグループを選ぶ
  4. Permission Set を選ぶ
  5. 対象アカウントに IAM Identity Center 管理の IAM ロールが作成される
  6. ユーザーは AWS アクセスポータルや CLI から一時認証情報を取得できる

この「対象アカウントにロールを作る」処理を意識しておくと、CloudTrail や IAM ロール一覧が読みやすくなります。

Permission Set を更新するとどうなるか

Permission Set にポリシーを追加・変更した場合、対象アカウント側の AWSReservedSSO_* ロールにも反映される必要があります。
IAM Identity Center のコンソールや API は、この反映をプロビジョニングとして扱います。

運用上は、次の点を覚えておくと便利です。

操作 影響
Permission Set のポリシー変更 割り当て済みアカウントのロール権限に反映が必要
アカウント割り当ての追加 対象アカウントに対応ロールが作成される
アカウント割り当ての削除 対応ロールが削除される場合がある
Permission Set 名の変更 ロール名や参照設計に影響する可能性がある

特に、EKS の aws-auth、KMS キーポリシー、S3 バケットポリシーなどで AWSReservedSSO_* ロール ARN を直接参照している場合は注意が必要です。
割り当て削除や再作成でロール ARN が変わると、参照先が壊れる可能性があります。

直接編集してよいのか

AWSReservedSSO_* ロールは IAM Identity Center が管理するロールです。
そのため、対象アカウントの IAM コンソールで直接ポリシーを付け替えるのではなく、Permission Set 側を更新するのが基本です。

直接編集しようとすると、次のような問題が起きやすくなります。

  • Permission Set の内容とアカウント内ロールの実態がずれる
  • 再プロビジョニング時に手作業の変更が上書きされる可能性がある
  • どの変更が正式な権限設計なのか追跡しにくくなる
  • Terraform や運用ドキュメントと実環境がずれる

権限を追加したい場合は、Permission Set に AWS 管理ポリシー、カスタマー管理ポリシー、インラインポリシーを追加する形で管理します。

CloudTrail ではどう見えるか

IAM Identity Center 経由で AWS CLI を使うと、認証情報取得と実際の API 操作は別のイベントとして見えます。

見る対象 代表的なイベント
IAM Identity Center で認証情報を取得した GetRoleCredentials
AWS アクセスポータルからコンソールへ入った Federate
対象アカウントで API を実行した AssumeRole セッションによる各サービスイベント

サービス操作側の CloudTrail では、ユーザーは assumed-role/AWSReservedSSO_... として記録されます。
つまり、操作ログを読むときは次の 2 つをつなげて考えます。

  • どの Permission Set 由来のロールか
  • そのロールセッションを使ったユーザーは誰か

ユーザー特定には、イベントによって onBehalfOf.userId や Identity Store API との突き合わせが必要になる場合があります。
単純に userName だけで追跡できるとは限らない点に注意してください。

CLI プロファイルとの対応

~/.aws/config の SSO プロファイルでは、sso_role_name に Permission Set 名を指定します。

[profile dev-readonly]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = DeveloperReadOnly
region = ap-northeast-1
output = json

ここで指定している DeveloperReadOnly が、対象アカウント側では AWSReservedSSO_DeveloperReadOnly_... という IAM ロールとして扱われます。
プロファイル名の dev-readonly はローカル PC 上の名前であり、AWS 側のロール名ではありません。

この違いを押さえておくと、次のような混乱を避けやすくなります。

名前 どこで使うか
dev-readonly ローカルの AWS CLI プロファイル名
DeveloperReadOnly IAM Identity Center の Permission Set 名
AWSReservedSSO_DeveloperReadOnly_... AWS アカウント内の IAM ロール名

削除や名前変更で注意すること

Permission Set やアカウント割り当てを整理するときは、参照関係を確認してから進めます。

特に注意したいのは、リソースベースポリシーで AWSReservedSSO_* ロール ARN を参照しているケースです。

  • KMS キーポリシー
  • S3 バケットポリシー
  • EKS のアクセス設定
  • 外部システム側の許可リスト
  • Terraform の IAM policy document

割り当て削除によってロールが消えると、同じ Permission Set を再割り当てしても ARN の suffix が変わることがあります。
重要なリソースでは、直接ロール ARN に依存しすぎない設計や、削除前の棚卸しが必要です。

まとめ

Permission Set は、AWS アカウント内では IAM Identity Center 管理の AWSReservedSSO_* ロールとして使われます。

概念 実体
Permission Set IAM Identity Center 上の権限テンプレート
アカウント割り当て ユーザー / グループ、アカウント、Permission Set の対応
AWSReservedSSO_* ロール 対象 AWS アカウントに作られる IAM ロール
CLI プロファイル ローカルから Permission Set を選ぶための設定
CloudTrail の操作主体 assumed-role/AWSReservedSSO_... として記録される

この仕組みを理解しておくと、CloudTrail のログ、AWS CLI の出力、IAM ロール一覧、Permission Set の変更影響をつなげて読めるようになります。

検証ステータス

参考文献

Discussion