2021

6

16

GCPの基本ロール権限をまとめてやんよ!!!

タグ: | | | |

Pocket
LINEで送る
Facebook にシェア
reddit にシェア
LinkedIn にシェア

GCPのプロジェクトを複数人で扱う場合に各アカウントに権限設定する際にIAMの基本ロールを付与するのが一般的ですが、意外と
「あれ?コンパネのこの操作できない」や
「あれ?このコマンド、権限エラーで効かないんですけど」といった事が多く
実はGCPでは与える権限によってできる操作範囲がかなり細かく定められていて意外とこのロールではできないというものが多いので自分の馴染みのあるサービスをまとめます。

IAMについて

Google Cloud Platformには利用するサービスごとに使える機能の範囲とその権限を与える事ができる Identity and Access Management(IAM)という物があります。

GCPのプロジェクトは主に「オーナー」「閲覧者」「参照者」「編集者」で区分けできますが、
すべての参画メンバーに対してプロジェクト全体に関わらせる必要は無いので、データベース担当者にはCloud SQLのサービス権限のみ与えるという設定が可能になります。

IAMを設定することで誰(ID)がどのリソースに対してどのようなアクセス権(ロール)を持つかを定義することにより、アクセス制御を管理します。
GCPのコンパネのメニューから「IAMの管理」-> 「IAM」から設定が可能です。

メンバーの設定

まずはIDとなる役割を与える対象がメンバーです。
IDを付与できるのは普段使っている個人のGoogleアカウントだけではなく、以下のサービスから与えられるアカウントも対象となります

  • GCPサービスにアプリや仮想マシンから接続を設定するサービス アカウント
  • 組織やクラス、チームなどを管理できるGoogle グループ
  • 各Googleサービスの企業向けグループウェアサービスのGoogle Workspace (旧称 G Suite)
  • Google Workspaceのさらにメンバーの利用端末なども管理できるCloud Identity ドメイン

①「IAM」ページの上部にある「+追加」から

②追加したいメンバーのアドレスやドメインとロールの設定をします

ロールの設定

メンバーに与える権限のコレクションです。要するにRPGの勇者や魔法使いといった役割の事ですね
権限によって、メンバーに対して付与される操作の許可範囲が決まります。

基本ロール

GCPのロールは4500を超える権限数と、利用するサービスによって使えるロール組み合わせを把握するのは至難の業ですので、この役割の人が使うであろう権限をGoogle様がおおまかに詰め合わせしてくれる基本ロールというものが存在します。


GCPサービスの基本ロール

やっと本題ですが、IAMの役割について理解ができたら、利用するサービスの基本ロールごとの権限を把握しましょう。

権限メソッドの概要については公式の詳細なドキュメントが無いため正確な機能がわからないものも多いですがエンジニアならだいたいわかると思うので割愛します。

App Engine編

参考: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デプロイ担当者の権限も与えなければいけません

まぁ冷静に考えたら要件にもマッチしないハイスペックのインスタンス勝手に何個も作られたら翌月の請求額とんでもないことになっちゃいますしね。


Cloud SQL編

参考: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に関しては管理者と編集者の堺はほとんど無いですね
cloudsqlInstanceDiskUsageTrendInsightscloudsqlInstanceDiskUsageTrendInsights は分析情報とレコメンデーションに使う権限だそうです。


Cloud Build編

参考: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関連サービスとの連携として機能する部分なので担当者の権限分けというよりはサービスアカウントを利用するか否かという感じです


Cloud Functions編

参考: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のように各ロールの権限が細かすぎて渡された側も把握できないサービスもあるので

Pocket
LINEで送る
Facebook にシェア
reddit にシェア
LinkedIn にシェア

トップへ