GCPのIAMを整理し始めています(前編: Googleグループ・IAM設計)

導入

みなさんこんにちは。ProductTeam SREのkterui9019です。

今回は、私たちがGoogle CloudのIAM権限を整理し始めていることについてお伝えします。 チームメンバーの入れ替わりやメンバーの入社・退職で発生する権限管理の課題に対する取り組みについて前後編に分けてお伝えします。

前編である今回は無秩序に設定されていたIAMロールのバインディングから、Googleグループを作って組織の階層構造に合ったフォルダ階層に整理した経験について書きます。 泥臭い内容にはなりますが、IAMロールを整理したいが何から手をつけていいかわからない…という方の助けになればと思います。

なぜやるのか

私たちが所属するProduct Teamという組織では、月に一度程度の頻度でチームシャッフル*1が行われ、人々の入れ替わりが頻繁に起こります。その結果、開発者が使用するGCPのプロジェクトも変化し、権限管理の負担が増加していました。

採用資料より: 定期的なチームシャッフルを実施しています

これまでは、権限不足の問題が発生するたびに、SWE（Software Engineer）に依頼されて付与していました。適切なGoogleグループが存在すればそのグループに対してIAMロールを付与し、グループが存在しない場合は個別のアカウントに付与するという運用を行っていました。

起きたこと

しかしながら、この運用方法では以下のような問題が起きるようになりました。

1. チームシャッフルによって関係がなくなったGCPプロジェクトの権限が残ってしまったこと。
2. 退職者のアカウントが無効化されたにもかかわらず、彼らのロールのバインディングが残り続けていたこと（Googleログインできないため直ちに実害はありませんが）。
3. チームシャッフルのたびにIAMロールの付与作業が発生し、手間と時間がかかるようになったこと。
4. 権限不足の問題が発生してから対応することになってしまったこと。

そこでこの問題に対して、GCPのIAMベストプラクティスを参考にしながら解決に動き始めました。

個人からGoogleグループへ

まず最初に取り組んだのは、個人に対してロールを付与するのではなく、Googleグループに対してロールを付与する運用への変更です。私たちの組織では、プロダクトごとに開発用と本番用のGCPプロジェクトが作成されているので、それに合わせてGoogleグループをプロダクト単位で作成しました。

プロダクト単位でGoogleグループを作成

あとはチームシャッフルが発生したタイミングでGoogleグループのメンバーを追加・削除することで実際のチーム体系とGoogleグループの同期を取るようにしました（ただしこのメンバー入れ替えは手動で行っています）。

Googleグループを整理したことによって新規に個人にIAMロールを付与することがなくなり、「Aさんは触れるけどBさんは権限がない」という権限のねじれが起こらなくなりました。

IAMの設計

Googleグループの用意ができたので、続いて最小権限の原則を満たすIAMの設計に着手しました。 IAMの設計においては、Figjamを使用して要件を満たす設計を考案しました。具体的には、誰（Googleグループ）がどのスコープ（GCPプロジェクト）で何を行いたい（IAMロール）のかという3つの軸を洗い出しました。 さらにこの際に「storage.viewerはオブジェクトのダウンロードができるのか？」といった各ロールの細かい挙動の疑問点を実際にテストしながら解消していきました。

Figjam上で満たすべき要件を固めていきます

Figjamでまとめていった結果、以下のように満たすべき要件を整理できました。

• 自身が担当するプロダクトの開発環境では、検証用途で全てのGCPリソースの編集が可能であること
• 自身が担当するプロダクトの本番環境では、全てのGCPリソースの閲覧とSecret Managerの編集、Cloud SQLへの接続ができること
• 自身が普段担当しないプロダクトに関しては、デバッグ用途でGCE、GKE、Logging、Monitoring等のサービスの閲覧ができること

必要な要件が明確になった時点で、フォルダによる階層化も検討しました。「全てのメンバーに与える権限」「各プロダクトに関わるメンバーにのみ与える権限」といった要件をそのままフォルダの階層構造に反映しました。最上位のフォルダでは前述のGCEやLogging等の主要サービスへのViewer権限を付与し、その下の各プロダクトのフォルダではCloud SQLへの接続など、担当プロジェクトで必要なロールを付与しました。

最終的に清書した構成図

まとめ

ここまで基本となるIAM設計が完了しました。まず個人に権限を振っていく運用を止めるためにGoogleグループを整備して、FigJamを使って必要となるIAM要件の整理とフォルダ設計を行いました。 実は、この取り組みの中で「障害対応のために一時的に本番環境でcontainer.developerのような強い権限が必要になる」というニーズも明らかになりました。次回は、この一時的なIAMロール付与を実現する「Just-In-Time Access」の仕組みについて詳しく取り上げます。

以上が、GCPのIAM整理に向けた私たちの取り組みについての記事の前編です。次回の記事もお楽しみに！

*1:*1:1ヶ月に一度いくつかのチームのメンバーをシャッフルしてProduct Team内の流動性を高める仕組みです