アカウントを分けたら、入口が三つになると思っていた
第6回から第8回までで、管理・本番・検証の三つのAWSアカウント、LabとProdのOU、Lab OUへ適用するSCPを用意しました。
アカウントを分ける前に気になっていたのは、ログイン方法まで三つに増えることでした。アカウントごとに別の認証情報を持ち、作業のたびに入口を探すのであれば、役割は分かれても日常の操作が複雑になります。
そこで、AWS Identity Centerの説明を繰り返すのではなく、今回は「一つの入口から三つの作業先を選べる状態」をどう作ったかに絞ります。
名前が一度に出てきて、つながりが見えなかった
設定時には、samekoro-admin、Samekoro-Administrators、AdministratorAccessという三つの名前が出てきます。第5回でも触れたとおり、最初はどれがログインする人で、どれが権限なのか少し混乱しました。
整理すると、今回の役割は次のとおりです。
samekoro-admin:AWS Access PortalへサインインするユーザーSamekoro-Administrators:ユーザーを所属させるグループAdministratorAccess:対象アカウントで使う権限を定義した許可セット
個別ユーザーへアカウントを一件ずつ割り当てるのではなく、samekoro-adminをグループへ所属させ、そのグループと許可セットを各AWSアカウントへ割り当てました。
三つのアカウントへ同じ組み合わせを割り当てた
対象にしたのは次の三つです。
samekoro-managementsamekoro-prodsamekoro-lab
IAM Identity Centerの許可セットは、ユーザーまたはグループと組み合わせてAWSアカウントへ割り当てます。許可セットを割り当てると、対象アカウントにはIAM Identity Centerが管理するロールが作られ、利用者はAWS Access Portalからその役割を選べるようになります。
設定画面を追っている間は、ユーザー、グループ、許可セット、AWSアカウントが別々の一覧に見えました。割り当てまで終えて初めて、これらが一本の経路としてつながりました。
AWS Access Portalに三つの作業先が並んだ
設定後、samekoro-adminでAWS Access Portalへサインインしました。そこにはsamekoro-management、samekoro-prod、samekoro-labの三つが表示されました。
以前は、アカウントを分けるとログイン入口も増えると思っていました。実際には、入口はAWS Access Portalへまとめたまま、入ったあとに作業先を選べます。
この画面でアカウント名が並んだことで、Organizationsで分けた構成が普段の操作へつながりました。組織図の中にあるアカウントではなく、自分が今から選ぶ作業場所として見えるようになりました。
表示されるだけで終わらせず、実際にログインした
ポータルに三つの名前が表示されても、割り当てが正しく動くとは限りません。そこで、それぞれを選び、AWSマネジメントコンソールへログインできることを確認しました。
確認できたのは、samekoro-adminから、Samekoro-AdministratorsとAdministratorAccessの組み合わせを使い、管理・本番・検証の三つへ入れることです。
アカウントIDや認証情報を記事へ残す必要はありません。公開する記録では、どの経路を作り、どこまで動作を確認したかだけを残します。
便利さと権限の強さは別に考える
一つのポータルから選べるようになると、入口はかなり扱いやすくなりました。一方、今回使っているAdministratorAccessは強い権限です。ログインが簡単になったことと、日常作業へ最小限の権限を使えていることは同じではありません。
今回は三つのアカウントへ入れる経路を確認する段階として、管理者用の許可セットを使いました。企業であれば職務や作業内容に合わせて複数の許可セットを用意し、必要な権限だけを選ぶ運用が必要です。
個人環境でも、将来は閲覧用や作業用を分ける余地があります。まず入口と割り当ての関係を実際に確認し、その次に権限の粒度を考える順番にしました。
まとめ
三つのAWSアカウントを作ったからといって、認証情報を三組持つ必要はありませんでした。AWS Access Portalを共通の入口にし、ユーザー、グループ、許可セット、対象アカウントを割り当てることで、作業先を選べる形にできました。
次に残った疑問は、AdministratorAccessまで使えるならルートユーザーと何が違うのか、ということです。第10回では、強い管理者権限とルートユーザーを同じものとして扱えない理由を、今回の構成に沿って整理します。