【攻略】AWS IAM Identity Center

はじめに

AWSのIAM関連はインフラエンジニアであれば誰もが通る道。
「だるい」、「意味わからん」、「なんとなく権限まわりのサービスっしょ」と漠然とした理解のまま、利用している人も少なくないはずと思っています（そう信じてる。。）。

今回はIAMサービスの中でも、「AWS IAM Identity Center」について説明していきたいと思います。

個人的な見解なので、間違っている可能性はあります！！

前提

Google WorkspaceでのSSOログインを想定しています。

AWS IAM Identity Centerとは

まず、AWS IAM Identity Centerを簡単に説明すると、
どこの、どいつが、どこへ、何の権限を持ってログインするかを管理するサービスです。

Googleアカウントの（どこの）、〇〇ユーザーが（どいつが）、〇〇アカウントへ（どこへ）、〇〇の権限を持って（何の権限を持って）ログインするか、を管理するサービスということです。

AWS IAM Identity Centerの設定について

前述したどこの、どいつが、どこへ、何の権限を持ってに着目して、どこで設定するのか理解しましょう。

どこの

「どこの」というのは、AWS IAM Identity Centerのアイデンティティソースで指定します。
指定可能な項目は以下で、今回で言うと「外部 ID プロバイダー」に当たります。

• Identity Center ディレクトリ
  • AWS内で管理
• Active Directory
  • Microsoft ADで管理
• 外部 ID プロバイダー ← 今回はこれ
  • Google WorkspaceやOktaなどで管理

どいつが

「どいつが」というのは、Google Workspace側で指定します。
管理者権限があれば、AWSというアプリケーションに対して、どのユーザがアクセスできるのかを指定することができます。

どこへ

「どこへ」というのは、Identity Centerで表示されているユーザのAWSアカウントで指定します。

何の権限を持って

「何の権限を持って」というのは、前述のAWSアカウントの指定と合わせて許可セットで指定します。

[重要!]ユーザへの権限付与の仕組み

前述の説明でユーザに権限を付与してログインするんだろうなというのは、何となくわかったと思います。
本記事で一番お伝えしたい部分が、ユーザへの権限付与の仕組みで、
インフラエンジニアであれば、この権限付与の仕組みは押さえておきたいポイントです。

結論からお伝えすると、ユーザがAssumeRoleを利用してログインしています。

AssumeRoleとはAWS STSのサービスの1つで、IAMロールに設定した権限を一時的に使えるようにTokenを発行する事を指します。
そしてこの発行されたトークンを利用して、ユーザがログインしているわけです。

何だよそんなことかよと思ったかもしれませんが、
重要なのはSSOユーザ自体は何の権限も持っていない、ただ存在する人であるということです。

会社の入館システムを思い浮かべて欲しいです。
社員の方はカードキーを持っているので、いつでも会社に入ることができます。
ですが、初めて訪問した新入社員や業務委託の方は、警備員さんが受付を行い、一時的なカードキーをもらって入館することがありませんでしたか？

まさにGoogle WorkspaceのユーザがSSO経由でAWSにログインするというが、それに当たります。
Google Workspaceと認証したユーザだから常に利用可能なカードキーを持っているわけではありません。

というのを本記事でお伝えしかったのです！

最後まで読んでいただきありがとうございました！！