G-gen の武井です。 Google Cloud (旧称 GCP) の Cloud IAM (Identity and Access Management) にて、権限不足に伴うエラーが発生した場合の対処方法について説明したいと思います。
簡単なおさらい
本題の説明に入る前に、まずは基本事項について簡単に振り返りたいと思います。
用語
Cloud IAM を理解する上で重要な用語と、それらの意味は以下のようになります。
用語 | 意味 |
---|---|
Google アカウント | IAM の実行主体 (人) |
Google グループ | 上記をグループ化したもの |
サービスアカウント | IAM の実行主体 (サービス) |
IAM ロール | 各種リソースに対して実行可能な権限のセット |
IAM ポリシー | 各種リソースに対して「誰が」、「何をできるか」を規定するもの |
図説
用語同士の関係を図と実例でご説明します。
Google アカウント / グループ (実行主体)
に対し、Compute Engine で VM マシンの作成や削除が可能な権限を含むIAM ロール
を付与- VM マシンに紐づけた
サービスアカウント (実行主体)
に対し、Cloud Storage でバケット内オブジェクトの表示や取得が可能な権限を含むIAM ロール
を付与 - 上記の関係性 (リソースに対し誰が何をできるか) を実現するために規定 (設定) したものが
IAM ポリシー
これらの概念については、以下の記事も参考にしてください。
IAM ロール
Google Cloud の各種リソースに対して特定の操作を実行可能にするための権限セットが IAM ロールです。実行主体 (Google アカウント / グループ、サービスアカウント) に対して付与します。
(Cloud IAM の設定画面上では IAM ロールの付与対象を「プリンシプル」と表します)
IAM ロールは以下の3種類の IAM ロールタイプ に分類されます。
タイプ | 管理者 | 特徴 |
---|---|---|
基本ロール | Google Cloud | Cloud IAM 導入前より存在。オーナー / 編集者 / 閲覧者 の 3 ロールのみ |
事前定義ロール | Google Cloud | 特定のサービス (リソース) へのアクセスを細かく制御したロール |
カスタムロール | ユーザー | ユーザーが指定する権限に応じたきめ細かなアクセス制御を可能としたロール |
上記のうち「基本ロール」には広い権限が含まれているため、可能であればより狭い範囲の権限を持つ 事前定義ロール か、ユーザー独自で管理可能な カスタムロール を選択することが推奨されています。
事象
実例をもとに、Cloud IAM の権限不足に起因するエラーが発生した際の対処方法について説明します。
Cloud Functions で動作するプログラムが Secret Manager のシークレット値を取得する処理で例外が発生しました。 Cloud Functions にはサービスアカウントを紐づけており、その権限でシークレット値を取得する想定です。
エラーログには、以下のメッセージが含まれています。
403 Permission 'secretmanager.versions.access' denied for resource 'projects/myproject/secrets/mysecret/versions/latest' (or it may not exist).
対処方法
原因と対処法の確認
Cloud Logging からエラーログを確認します。以下は実際のスクリーンショットです。先ほど記載したものと同様のエラーメッセージが表示されています。
ログには secretmanager.versions.access
と記されていることから、この権限が不足していることで例外が発生していると推測できます (あるいはこのシークレットが存在していない可能性もありますが、存在は確認できているものとします) 。
このことから、Cloud Functions に紐づけているサービスアカウントに対して、上記の権限を含む IAM ロールを紐づけることでエラーが解消できると判断します。
最適な IAM ロールの選択
最適な IAM ロールを選択する際に役立つのが Cloud IAM の公式リファレンスです。
IAM permissions reference
ある権限がどのロールに含まれているかを確認するには IAM permissions reference というドキュメントを使います。
このドキュメントは 権限名から IAM ロールを検索 できるようになっており、今回のようなエラーが発生した際に活用できます。
今回の例では secretmanager.versions.access
という権限が不足していましたので、この権限がどの IAM ロールに含まれるか調べてみます。
使い方としては簡単で、リファレンス内の Search for a permission にある検索ボックスに権限名を入力するだけで IAM ロールが提示されます。
Understanding roles
次に最適な IAM ロールの選択です。最小権限の原則にもとづき、必要最低限の権限セットで構成された IAM ロールを選択します。
その際役に立つのが Understanding roles というドキュメントです。このドキュメントでは各 IAM ロールに何の権限が含まれているかを確認できます。
以下は IAM ロールの記載の例です。
オーナー (roles/owner)
Secret Manager 管理者 (roles/secretmanager.admin)
Secret Manager のシークレット アクセサー (roles/secretmanager.secretAccessor)
roles/owner
や roles/secretmanager.admin
は、エラーは解決できますが最適なロールではありません。なぜなら今回実現したい操作は「シークレット値の取得」だけですが、必要以上の権限が付与されているためです。
最小権限の原則にもとづけば、roles/secretmanager.secretAccessor
がより適切であるとわかります。
ロール名 | 概要 | 評価 |
---|---|---|
roles/owner | オーナー権限レベル | △ |
roles/secretmanager.admin | Secret Manager の管理者レベル | △ |
roles/secretmanager.secretAccessor | シークレットへのアクセスを許可 | ◯ |
IAM ロールの付与
最適な IAM ロールが選択できたら、あとはそれをサービスアカウントや Google アカウントに紐づけることでエラーが解消されます。
武井 祐介 (記事一覧)
クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア
Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。
趣味はロードバイク、ロードレースやサッカー観戦です。
Follow @ggenyutakei