GCP IAM

なんとなく IAM を使っている節があるので、ちゃんとドキュメント読むスレ

アクセス管理モデルは、次の 3 つの主要な部分から構成されています。

プリンシパル。プリンシパルは、リソースへのアクセスが許可されている Google アカウント（エンドユーザー）、サービスアカウント（アプリケーションまたはコンピューティングワークロード）、Google グループ、Google Workspace アカウントまたは Cloud Identity ドメインです。各プリンシパルには、一意の識別子（通常はメールアドレス）があります。

ロール。ロールは権限のコレクションです。権限によって、リソースに対して許可されているオペレーションが決まります。プリンシパルにロールを付与すると、そのロールに含まれるすべての権限が付与されます。

ポリシー。許可ポリシーは、1 つ以上のプリンシパルを個々のロールにバインドするロールバインディングの集合です。リソースに対してどのようなアクセス権（ロール）を誰（プリンシパル）に許可するのかを定義する場合、許可ポリシーを作成して、そのポリシーをリソースに接続します。

Kazuki Matsuda

プリンシパルのタイプ

Google アカウント
サービスアカウント
- 個々のエンドユーザーではなく、アプリケーションまたはコンピューティングワークロードのアカウント
Google グループ
- Google アカウントとサービスアカウントの名前付きコレクション
Google Workspace アカウント
- Google Workspace アカウントは、example.com などの組織のインターネットドメイン名に関連付けられている
Cloud Identity ドメイン
- Cloud Identity ドメインは、1 つの組織内のすべての Google アカウントの仮想グループを表すため、Google Workspace アカウントに似ています。ただし、Cloud Identity ドメインユーザーは、Google Workspace のアプリケーションと機能にアクセスできません。
認証済みのすべてのユーザー
- allAuthenticatedUsers は、すべてのサービスアカウント、および Google アカウントで認証されたユーザー全員を表す特殊な識別子
すべてのユーザー
- allUsers は、認証されたユーザーと認証されていないユーザーの両方を含めて、インターネット上のユーザーを表す特殊な識別子

Kazuki Matsuda

権限

権限によって、リソースに対して許可されているオペレーションが決まります。IAM では、権限を service.resource.verb の形式で表します（例: pubsub.subscriptions.consume）。

多くの場合、権限は REST API メソッドと 1 対 1 で対応しています。つまり、Google Cloud の各サービスには、各 REST API メソッドに対して関連付けられている権限のセットがあります。そのメソッドの呼び出し元は、そのメソッドを呼び出すための権限を持っている必要があります。たとえば、Pub/Sub を使用し、topics.publish() メソッドを呼び出す必要がある場合は、そのトピックに対して pubsub.topics.publish 権限が必要になります。

ユーザーに直接権限を付与することはできません。代わりに、必要な権限を含むロールを指定し、そのロールをユーザーに付与します。

Kazuki Matsuda

ロール

ロールは権限のコレクションです。ユーザーに直接権限を付与することはできません。代わりに、ロールを付与します。ユーザーにロールを付与する際には、そのロールに含まれているすべての権限がユーザーに付与されます。

ロールの種類

基本ロール
- Google Cloud Console で従来から使用されているロール。オーナー、編集者、閲覧者のロールがある。
事前定義ロール
- 基本ロールよりも詳細なアクセス制御が可能なロール。たとえば、Pub/Sub パブリッシャー（roles/pubsub.publisher）は事前定義ロール。
カスタムロール
- 事前定義ロールがニーズを満たしていない場合に、組織のニーズに応じて権限を調整するために作成するロール。

Kazuki Matsuda

許可ポリシー

許可ポリシーは、誰がどの種類のアクセス権を持つかを定義するステートメントの集合です。これを作成することによって、ユーザーにロールを付与できます。許可ポリシーはリソースに関連付けられ、そのリソースがアクセスされると常にアクセス制御が適用されます。

許可ポリシーは、ロールバインディングリストで構成されています。ロールバインディングはプリンシパルのリストをロールにバインドします。

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:ali@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:admins@example.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

role
- プリンシパルに付与するロール。role は、roles/service.roleName の形式で指定
members
- ロールを付与するプリンシパルのリスト
- 各プリンシパルタイプは接頭辞で識別さる
- Google アカウントには user:、サービスアカウントには serviceAccount:、Google グループには group:、Google Workspace アカウントまたは Cloud Identity ドメインには domain: が付く

Kazuki Matsuda

リソース階層

許可ポリシーは、リソース階層の任意のレベル（組織レベル、フォルダレベル、プロジェクトレベル、リソースレベル）で設定できます。リソースは親リソースの許可ポリシーをすべて継承します。リソースで有効な許可ポリシーは、そのリソースに設定された許可ポリシーと、上位階層から継承された許可ポリシーを組み合わせたものです。