Google Cloud IAM で 「最小権限の原則」 を試してみた

アノテーション、Google Cloud が大好きな村上です。
今回は、「開発者には必要最小限の権限だけを与えたい」と考えて設定を進めた際に、見事にエラーの連続にハマってしまった経験と、その解決プロセスを共有したいと思います。この記事は、IAMの権限設定で同じように悩んだことがある方や、これからカスタムロールを使ってみようと考えている方の参考になるかと思います。

目標：開発者グループに必要最小限のロールを付与する

まず、私がやろうとしていたことを説明します。
Cloud Identity で作成済みの developer-group@example.com というグループに対し、開発業務で必要となりそうな複数の事前定義ロールを割り当てる、という計画でした。具体的には、Google Cloud コンソールの IAM ページで、「アクセス権を付与」を選択し、プリンシパルとして developer-group@example.com を指定します。

そして、このグループに以下のロールを割り当てました。

• Cloud Build 編集者
• Artifact Registry 書き込み
• Cloud Run デベロッパー
• Cloud SQL クライアント
• など...
  

ここまでは計画通りでした。しかし、このグループに所属するユーザーでログインしたところ、さっそく最初の壁にぶつかります。

最初の壁 「追加のアクセス権が必要です」 エラー

検証用ユーザーで Google Cloud コンソールにログインしたところ、表示されたのは以下のエラーメッセージでした。

「追加のアクセス権が必要です」
「次の権限がありません: resourcemanager.projects.getIamPolicy」

プロジェクトのリソースを編集するどころか、プロジェクト自体にアクセスするための基本的な権限が不足しているようでした。エラーメッセージ 「次の権限がありません: resourcemanager.projects.getIamPolicy」 は、そのプロジェクトに設定されている IAM ポリシー（誰が何をできるかの一覧）を読み取るための権限です。これが無いと、コンソールはユーザーがそのプロジェクトで何をして良いのかを判断できないため、このようなエラーが表示されます。

なぜ getIamPolicy が必要なのか？AWSとの考え方の違い

ここで、なぜプロジェクトを見るだけなのに getIamPolicy という権限が必要になるのか、疑問に思った方もいるかもしれません。これは、Google Cloud と AWS の IAM に関する根本的な考え方の違いに起因します。

AWS の IAM ポリシーが IAM ユーザーや IAM ロールに渡す権限の許可証だとすると、Google Cloud の IAM ポリシーは場所（組織・フォルダ・プロジェクト）やリソース（VM インスタンス、BigQuery 等）に貼ってあるルール一覧のようなイメージです。学校を舞台に考えてみると、Google Cloud と AWS では以下のような違いがあります。

	Google Cloud	AWS
考え方	場所や物にルールを貼る	人に許可証を渡す
例	教室のドアに入室ルールの貼り紙を貼る	生徒に鍵や許可証を渡す
主役	モノ（ドア、運動場、ノートなど）	ヒト（ユーザー、プログラムなど）
利用時の確認方法	この場所や物にはどんなルールがある？	この人はどんな許可を持っている？

AWS にもリソースベースのポリシーが存在するため、すべてが上記の表のとおりになるわけではありませんが、IAM の権限周りの仕組みは Google Cloud と AWS ではかなり異なる印象を持ちました。

解決策(1) カスタムロールで「IAM ポリシーを見る」権限を追加する

この問題を解決するため、新しいカスタムロールを作成し、不足している権限を追加することにしました。

管理者アカウントでIAMページの「ロール」に移動し、「ロールを作成」をクリックします。
ロール名に Role for login と入力し、「権限を追加」を選択します。

フィルタで resourcemanager.projects.getIamPolicy を検索し、IAM ロール Role for login に権限を追加してカスタムロールを作成します。

作成したカスタムロールを、IAM グループ developer-group に割り当てます。

この設定により、検証用ユーザーでログインすると、プロジェクトのトップページが表示されるようになりました。しかし、安堵したのも束の間、次の壁が待ち構えていました。

次なる壁 「Cloud SQLのインスタンスが見えません」 エラー

まずは Cloud SQL の設定でも確かめようと考え、Cloud SQL のページを開こうとしたところ、またしても見覚えがあるようなエラー画面が表示されました。

エラーメッセージには cloudsql.instances.list が不足していると示されました。これはその名の通り、プロジェクト内のCloud SQLインスタンスの一覧を表示するための権限です。

Cloud SQL の権限

解決策(2) インスタンスリスト取得用のカスタムロールを作成する

再び管理者アカウントに戻り、カスタムロール List of instances ロールを作成し、今度は cloudsql.instances.list 権限を追加で付与しました。

この修正後、三度目の正直でログインし直したところ、ついに Cloud SQL のコンソール画面を正常に表示させることができました。

まとめ

今回の検証を通して、IAM の権限管理について私が得た学びは以下の 3 点です。

1. 最小権限の追求は、時に地道なトライアンドエラーを伴う
   セキュリティを意識するあまり権限を絞りすぎると、今回のように基本的な操作すらできなくなることがあります。サービス間の依存関係は複雑で、ドキュメントに明記されていない暗黙的な権限が必要になるケースもあります。

2. エラーメッセージは解決への最大のヒント
   一見すると厄介なエラーメッセージですが、そこには「どの権限が不足しているか」という明確な答えが書かれています。焦らずに内容を読み解き、一つずつ対処していくことが、解決への一番の近道です。

3. 事前定義ロールとカスタムロールのバランスが重要
   カスタムロールでゼロから権限を積み上げるのは、非常に手間がかかります。実務では、まず想定している作業が可能であろう事前定義ロールを付与し、そこから本当に不要な権限を引いていく、あるいはベースとなる事前定義ロールに加えて必要な権限をカスタムロールで追加していく、というアプローチの方が効率的かもしれません。IAMの権限設定は、知識だけでなく実践的な経験とバランス感覚が問われる分野だと改めて感じました。

この記事が、同じように権限設定で試行錯誤している方の一助となれば幸いです。

参考資料

• resourcemanager.projects.getIamPolicy
• Cloud SQL の権限