AWSのログイン方法を切り替えた話
こんにちは。
株式会社ココナラのシステムプラットフォーム部インフラ・SREチームに所属している ぐっさん です。
本記事ではココナラで利用しているAWSのログイン方法の仕組み見直しを行ったので紹介したいと思います。
経緯
先日、弊社の かたぎり が公開した ココナラのAWS Organizationsを再構築しよう にある通り、ココナラのAWSアカウント管理体制がAWS Control Towerを用いた形に移行されました。
その結果、AWS IAM Identity Center（以降、Identity Centerと記載）を利用したSingle Sign On（以降、SSOと記載）が利用できる環境になりました。
詳細は後述いたしますが、将来的なアカウント追加や権限管理において既存の仕組みでは限界が見えていたことや、利便性向上を見据えてAWS Control Towerに移行したタイミングでIdentity Centerの導入に踏み切ることとなりました。
これまでの仕組み
Identity Centerの導入前は、Google WorkspaceをIdentify Provider（以降、IdPと記載）としたSAML認証を行いSSOを利用していました。
この仕組みでもSSOはできており、利用するAWSアカウントの数が少ない状況では大きな問題はありませんでした。
上記の図はユーザーとAWSアカウントの関係を表した略図になりますが、ユーザーと特定のAWSアカウントに存在するロールが1対1で紐づく形となっています。
ユーザーはGoogle Workspaceに登録されているユーザーアカウントを利用する形を採っていますが、結果、今後アカウントを追加していくにあたり下記の点で課題になりそうだと感じていました。
- AWSアカウントやロールを切り替える場合に、スイッチロールを用いる必要がある
- 権限の管理がユーザー個別に紐づいている
AWSアカウントやロールを切り替える場合に、スイッチロールを用いる必要がある
スイッチロール自体は一般的なAWSのアカウント切り替えの方法になりますが、過去利用したアカウントの履歴が5つしか残りません。
そのため、切り替える先のアカウントやロールの数が増えるとユーザー側で管理するアカウント情報の数が増え、管理が煩雑になることが予想されます。
特に、あまり利用されないアカウントやロールについては必要なアカウント情報を忘れてしまったりすることもあるかと思います。
権限の管理がユーザー個別に紐づいている
こちらは管理者側から見たときの話となりますが、AWSに対する権限はGoogle Workspaceにて登録されているユーザーに、ある特定のパラメーターに設定を記載することでAWSにあらかじめ登録していたロールと紐づく形となります。
そのため、どのユーザーがAWSのどのロールに紐づいているかが直感的には分かりづらい状態となっていました。
また、AWSログイン時にユーザーの紐付け対象となるロールの数はそれほど多くなく、ある程度の職域の単位で紐付け先を設定している関係上、特定の個人に対して権限を付与するのは困難でした。
AWS IAM Identity Centerの導入
AWS IAM Identity Centerについて
Identity Centerを導入することで、これまでとどう変化するかを簡単に説明します。
Identity Centerによる管理移行後は、各ユーザーに付与されているロールを選択し、AWSにログインすることができます。
以下はユーザーとAWSアカウントの関係を簡単にですが表した図になります。
もう少し詳細にお話しすると、ココナラで利用している複数のAWSアカウントを集中管理している管理アカウントで、Identity Centerにユーザーやグループ、ロールの情報を登録します。
登録された情報を基に被管理アカウントにユーザーとロールの設定を行うことにより、ココナラで管理しているAWSアカウントを横断してユーザーやロールの設定を行います。
従来の方式ではGoogle Workspaceに登録されているユーザーの特定パラメーターの設定値に対応したロールが割り当てられると記載しましたが、Identity Centerを利用後は紐づく対象が変わるためこのような設定ができます。
Identity Centerを用いた方式では、Google Workspaceに登録されているユーザーとIdentity Centerに登録されているユーザーが直接紐づく形となり、マッチングの条件としてはメールアドレスを利用しています。
導入初期の課題
IdPは従来通りGoogle Workspaceを使用し、Identity Centerの導入を検討しました。
実際の導入作業についてはAWS社にて公開されている記事 How to use Google Workspace as an external identity provider for AWS IAM Identity Center を参考に、初期の導入を実施しました。
導入作業自体は特に大きな問題もなく、スムーズに導入することができました。
ですが、この状態ではアカウントやグループの管理を行うにあたり、一人ひとりユーザーを手動で管理アカウントのIdentity Centerに登録する必要があることが判明しました。
グループも同様の状態であるため、この状態ではGoogle WorkspaceとAWSとでユーザーの二重管理となってしまい、かえって運用負荷が上がってしまう可能性があります。
この問題を解決しないことには本格的に導入するのは難しいため、解決する方法がないか、調査・検討を続けました。
課題への対策
先の課題に対する対応策は幸いなことに簡単に見つけることができました。
具体的にはIdentity Center導入の参考としていたページにて紹介されていたssosyncを導入しました。
こちらのOSSを導入することで平日の業務時間の間、一定のタイミングでGoogle Workspaceに登録されている所定のグループとグループに所属しているユーザーが自動で登録・削除されるようになりました。
これにより、Google Workspaceをマスターとしてユーザーとグループの一元管理を行える環境となりました。
切り替えるにあたり気をつけたこと
エンジニアは常日頃AWSを利用していることから、切り替え時にできること・できないことに差異が出ないようには気をつけました。
具体的には、従来利用していたロールにはカスタムポリシーがかなりの割合で利用されていたため、Identity Centerに切り替え後もこれまで利用していたカスタムポリシーをそのまま継続して使用することにしました。
Identity Centerで設定するロールはココナラのAWSアカウント全体に適用可能なロールとなりますが、特定のAWSアカウントにしか存在しないカスタムポリシーも利用することができます。[1][2]
導入してみて
AWSを管理コンソールからログインする際に許可されているアカウントの中からアタッチされている権限を選択するだけで済む点がスイッチロールと比較して直感的で利用しやすいと感じました。
AWS CLIを使用する場合でもスイッチロールと比較して設定がシンプルな点や、ログインの認証がコマンドを1回叩いた後に表示されるブラウザのページに対しワンクリックするだけで済むなど、手軽に利用できるようになりました。
些細なことですが日々利用するものなので、このような改善は大切だと考えています。
反面、少し対応が必要だったところとして、TerraformでAWS CLIを用いた認証情報は利用する際に、一部、古いバージョンを利用していたところがあり修正が必要でした。
上記は一般ユーザーとして使用したときの感想ですが、管理者として利用した際の感想としては、必要に応じてロールの確認やアタッチが直感的にできるのが非常に便利です。
特に、AWSアカウントに対しグループ単位でロールの付与ができ、グループ自体の管理はGoogle Workspaceに寄せることができるので、AWSのみならず組織全体で一貫した権限管理が可能となりました。
特定の個人に対しロールの付与もできるため、非常に柔軟にロールの管理ができると感じています。
最後に補足となりますが、Identity Center導入における課題の一つとして挙げていたIdentity CenterとGoogle Workspace間のユーザー同期ですが、先日、Identity CenterとGoogle Workspaceが自動で同期するようになったと発表がありました。
手順を確認してみたところ、Identity Centerに追加で設定を少し行うことで、ユーザーの自動同期が行われる環境が実現できそうでした。
簡単にではありますが、AWSのログイン方法の仕組みを見直したときのことを紹介させていただきました。
AWSのユーザー管理に悩んでいる方の参考になれば幸いです。
ココナラでは一緒に働く方を募集しています。
インフラ・SREだけでなく幅広く募集していますので、ご興味ある方はぜひご応募ください！
ブログの内容への感想、カジュアルにココナラの技術組織の話をしてみたい方はこちら ※ブログ閲覧者の方限定のカジュアル面談の応募フォームとなります！
エンジニアの募集職種一覧はこちら
Discussion