タグ:Google App Engine | Google Cloud Build | Google Cloud Functions | Google Cloud Platform | Google Cloud SQL
GCPのプロジェクトを複数人で扱う場合に各アカウントに権限設定する際にIAMの基本ロールを付与するのが一般的ですが、意外と
「あれ?コンパネのこの操作できない」や
「あれ?このコマンド、権限エラーで効かないんですけど」といった事が多く
実はGCPでは与える権限によってできる操作範囲がかなり細かく定められていて意外とこのロールではできないというものが多いので自分の馴染みのあるサービスをまとめます。
Google Cloud Platformには利用するサービスごとに使える機能の範囲とその権限を与える事ができる Identity and Access Management(IAM)という物があります。
GCPのプロジェクトは主に「オーナー」「閲覧者」「参照者」「編集者」で区分けできますが、
すべての参画メンバーに対してプロジェクト全体に関わらせる必要は無いので、データベース担当者にはCloud SQLのサービス権限のみ与えるという設定が可能になります。
IAMを設定することで誰(ID)がどのリソースに対してどのようなアクセス権(ロール)を持つかを定義することにより、アクセス制御を管理します。
GCPのコンパネのメニューから「IAMの管理」-> 「IAM」から設定が可能です。
まずはIDとなる役割を与える対象がメンバーです。
IDを付与できるのは普段使っている個人のGoogleアカウントだけではなく、以下のサービスから与えられるアカウントも対象となります
①「IAM」ページの上部にある「+追加」から
②追加したいメンバーのアドレスやドメインとロールの設定をします
メンバーに与える権限のコレクションです。要するにRPGの勇者や魔法使いといった役割の事ですね
権限によって、メンバーに対して付与される操作の許可範囲が決まります。
GCPのロールは4500を超える権限数と、利用するサービスによって使えるロール組み合わせを把握するのは至難の業ですので、この役割の人が使うであろう権限をGoogle様がおおまかに詰め合わせしてくれる基本ロールというものが存在します。
やっと本題ですが、IAMの役割について理解ができたら、利用するサービスの基本ロールごとの権限を把握しましょう。
権限メソッドの概要については公式の詳細なドキュメントが無いため正確な機能がわからないものも多いですがエンジニアならだいたいわかると思うので割愛します。
参考:https://cloud.google.com/appengine/docs/standard/php7/roles?hl=ja
機能 / 権限メソッド | 管理者 | 作成者 | 閲覧者 | コード 閲覧者 | デプロイ 担当者 | サービス 管理者 |
appengine applications.get | ○ | ○ | ○ | ○ | ○ | |
appengine applications.update | ○ | |||||
appengine applications.create | ○ | |||||
appengine operations.* | ○ | ○ | ○ | ○ | ○ | |
appengine runtimes.* | ○ | |||||
appengine versions.create | ○ | ○ | ||||
appengine versions.delete | ○ | ○ | ○ | |||
appengine versions.get | ○ | ○ | ○ | ○ | ○ | |
appengine versions.list | ○ | ○ | ○ | ○ | ○ | |
appengine versions.update | ○ | ○ | ||||
appengine versions.getFileContents | ○ | |||||
resourcemanager projects.get | ○ | ○ | ○ | ○ | ○ | ○ |
resourcemanager projects.list | ○ | ○ | ○ | ○ | ○ | ○ |
appengine instances.get | ○ | ○ | ○ | ○ | ○ | |
appengine instances.list | ○ | ○ | ○ | ○ | ○ | |
appengine services.get | ○ | ○ | ○ | ○ | ○ | |
appengine services.list | ○ | ○ | ○ | ○ | ○ |
上記の通り、App Engine 管理者のロールだけでは新規アプリを作成(applications.create)することはできず、
オーナーではないユーザーがgcloudコマンドでデプロイする場合、App Engine管理者ロールの他にApp Engine作成者とApp Engineデプロイ担当者の権限も与えなければいけません
まぁ冷静に考えたら要件にもマッチしないハイスペックのインスタンス勝手に何個も作られたら翌月の請求額とんでもないことになっちゃいますしね。
参考:https://cloud.google.com/iam/docs/understanding-roles?hl=ja#cloud-sql-roles
機能 / 権限メソッド | 管理者 | 編集者 | インスタンス ユーザー | 閲覧者 | クライアント |
cloudsql instances.connect | ○ | ○ | ○ | ||
cloudsql instances.get | ○ | ○ | ○ | ○ | ○ |
cloudsql instances.list | ○ | ○ | ○ | ||
cloudsql instances.export | ○ | ○ | ○ | ||
cloudsql instances.restart | ○ | ○ | |||
cloudsql instances.update | ○ | ○ | |||
cloudsql instances.login | ○ | ○ | |||
cloudsql instances.addServerCa | ○ | ○ | |||
cloudsql instances.listServerCas | ○ | ○ | |||
cloudsql instances.rotateServerCa | ○ | ○ | |||
cloudsql instances.truncateLog | ○ | ○ | |||
cloudsql backupRuns.create | ○ | ○ | |||
cloudsql backupRuns.get | ○ | ○ | ○ | ||
cloudsql backupRuns.list | ○ | ○ | ○ | ||
cloudsql databases.create | ○ | ○ | |||
cloudsql databases.get | ○ | ○ | ○ | ||
cloudsql databases.list | ○ | ○ | ○ | ||
cloudsql databases.update | ○ | ○ | |||
cloudsql sslCerts.get | ○ | ○ | ○ | ||
cloudsql sslCerts.list | ○ | ○ | ○ | ||
cloudsql users.list | ○ | ○ | ○ | ||
recommender cloudsqlInstance DiskUsageTrendInsights.get | ○ | ○ | ○ | ||
recommender cloudsqlInstance DiskUsageTrendInsights.list | ○ | ○ | ○ | ||
recommender cloudsqlInstance OutOfDiskRecommendations.get | ○ | ○ | ○ | ||
recommender cloudsqlInstance OutOfDiskRecommendations.list | ○ | ○ | ○ | ||
resourcemanager projects.get | ○ | ○ | ○ | ||
resourcemanager projects.list | ○ | ○ | ○ | ||
serviceusage quotas.get | ○ | ○ | ○ | ||
serviceusage services.get | ○ | ○ | ○ | ||
serviceusage services.list | ○ | ○ | ○ |
Cloud SQLに関しては管理者と編集者の堺はほとんど無いですねcloudsqlInstanceDiskUsageTrendInsights
とcloudsqlInstanceDiskUsageTrendInsights
は分析情報とレコメンデーションに使う権限だそうです。
参考:https://cloud.google.com/iam/docs/understanding-roles#cloud-build-roles
機能 / 権限メソッド | サービス アカウント | 編集者 | 閲覧者 |
cloudbuild.builds.get | ○ | ○ | ○ |
cloudbuild.builds.list | ○ | ○ | ○ |
storage.buckets.create storage.buckets.get storage.buckets.list | ○ | ||
storage.objects.create storage.objects.delete storage.objects.get storage.objects.list storage.objects.update | ○ | ||
source.repos.get source.repos.list | ○ | ||
resourcemanager.projects.get resourcemanager.projects.list | ○ | ○ | ○ |
remotebuildexecution.blobs.get | ○ | ○ | ○ |
artifactregistry.files.* artifactregistry.packages.get artifactregistry.packages.list artifactregistry.repositories.downloadArtifacts artifactregistry.repositories.get artifactregistry.repositories.list artifactregistry.repositories.uploadArtifacts artifactregistry.tags.create artifactregistry.tags.get artifactregistry.tags.list artifactregistry.tags.update artifactregistry.versions.get artifactregistry.versions.list | ○ | ||
containeranalysis.occurrences.create containeranalysis.occurrences.delete containeranalysis.occurrences.get containeranalysis.occurrences.list containeranalysis.occurrences.update | ○ | ||
logging.logEntries.create | ○ | ||
pubsub.topics.create pubsub.topics.publish | ○ |
Cloud Build自体はデプロイ対象のリソース状態の確認以外はSource RepositoriesやArtifact RegistryなどのCI/CD関連サービスとの連携として機能する部分なので担当者の権限分けというよりはサービスアカウントを利用するか否かという感じです
参考:https://cloud.google.com/iam/docs/understanding-roles#cloud-functions-roles
機能 / 権限メソッド | 管理者 | デベロッパー | 起動元 (アクセス制限の関数) | 閲覧者 (読み取り専用) |
cloudfunctions functions.call | ○ | ○ | ||
cloudfunctions functions.create | ○ | ○ | ||
cloudfunctions functions.delete | ○ | ○ | ||
cloudfunctions functions.get | ○ | ○ | ○ | |
cloudfunctions functions.invoke | ○ | ○ | ○ | ○ |
cloudfunctions functions.list | ○ | ○ | ○ | |
cloudfunctions functions.sourceCodeGet | ○ | ○ | ||
cloudfunctions functions.sourceCodeSet | ○ | ○ | ||
cloudfunctions functions.update | ○ | ○ | ||
cloudfunctions.locations.* cloudfunctions.operations.* | ○ | ○ | ○ | |
eventarc.locations.* | ○ | ○ | ○ | |
eventarc.operations.get eventarc.operations.list | ○ | ○ | ○ | |
eventarc.triggers.create eventarc.triggers.delete | ○ | ○ | ||
eventarc.triggers.get eventarc.triggers.getIamPolicy | ○ | ○ | ○ | |
eventarc.triggers.list | ○ | ○ | ○ | |
eventarc.triggers.undelete eventarc.triggers.update | ○ | ○ | ||
recommender.locations.* | ○ | ○ | ○ | |
remotebuildexecution.blobs.get | ○ | ○ | ○ | |
resourcemanager.projects.get resourcemanager.projects.list | ○ | ○ | ○ | |
run.configurations.* | ○ | ○ | ○ | |
run.locations.* | ○ | ○ | ○ | |
run.revisions.get run.revisions.list | ○ | ○ | ○ | |
run.routes.get run.routes.list | ○ | ○ | ○ | |
run.services.get run.services.getIamPolicy run.services.list | ○ | ○ | ○ | |
run.services.update | ○ | ○ | ||
serviceusage.quotas.get | ○ | ○ | ○ | |
serviceusage.services.get serviceusage.services.list | ○ | ○ | ○ |
Cloud Functionsもソースコードのロジック内でイベント操作させるので、デベロッパーがほぼ管理者と同等の権限を保有しています。
当初はWordpressのように管理者がすべての権限を持っているものだと思って管理者権限だけ渡したら、実はそれだけでは色々できないことが多い落とし穴に注意しましょう。
とはいえCompute Engineのように各ロールの権限が細かすぎて渡された側も把握できないサービスもあるので