【Terraform】Google Cloud Storage バケットのIAM管理:3つの異なる粒度(policy, binding, member)でのポリシー設定方法と使い分けの解説

【Terraform】Google Cloud Storage バケットのIAM管理:3つの異なる粒度(policy, binding, member)でのポリシー設定方法と使い分けの解説

表題の通り、GCSのバケットに対するアクセス制御についてTerraformコードを交えながら解説します。
Clock Icon2024.07.01 23:43

概要

今回は以下のTerraformの公式サイトからの情報をアウトプットしていきます。
自身で調べていても、少しわかりにくかったので理解のためのTipsとして使用いただければ幸いです。

3つの範囲でポリシーを指定する

バケットのIAMポリシー全体を設定

data "google_iam_policy" "admin" {
  binding {
    role = "roles/storage.admin"
    members = [
      "user:jane@example.com",
    ]
  }
}

resource "google_storage_bucket_iam_policy" "policy" {
  bucket = google_storage_bucket.default.name
  policy_data = data.google_iam_policy.admin.policy_data
}

data google_iam_policy adminの部分は、dataブロックを利用して、IAMポリシーを定義しています。このブロックは、実際にリソースを作成するのではなく、設定を記述するためのものです。

  • google_iam_policy
    • タイプのデータソースを使って、IAMポリシーの内容を記述します。
  • admin
    • このデータソースにつけた名前で、後で参照するために使います。
  • binding
    • このブロックの中で、実際の権限設定を行います。
    • role = roles/storage.adminは、ストレージ管理者の役割を指定しています。
    • members = user:jane@example.comには、この役割を与えるユーザーを列挙します。

resource google_storage_bucket_iam_policy policyの部分は、通常のようにTerraformでリソースを定義する箇所となります。

  • bucket
    • 対象のバケット(google_storage_bucket.default.name)を指定します。
  • policy_data
    • 先程作成したポリシー(data.google_iam_policy.admin.policy_data)を指定します。

コードにするとわかりずらいですが、ポリシーを作成→バケットに適応というGoogle Cloud コンソールと同じような操作だと考えていいと思います。(よって最も大きな粒度でのポリシーの変更となります)

特定のプリンシパルに対して権限を付与

resource "google_storage_bucket_iam_binding" "binding" {
  bucket = google_storage_bucket.default.name
  role = "roles/storage.admin"
  members = [
    "user:jane@example.com",
  ]
}

resource google_storage_bucket_iam_binding bindingの部分は、通常のようにTerraformでリソースを定義する箇所となります。このリソースは、特定のロールに対するメンバーリストを管理します。

  • bucket
    • 対象のバケット(google_storage_bucket.default.name)を指定します。
  • role
    • 設定するロール(roles/storage.admin)を指定します。この例ではストレージ管理者の役割を設定しています。
  • members
  • このロールを与えるメンバーのリストを指定します。(user:jane@example.comを指定)

このリソースは、指定されたバケットのポリシーにおいて、特定のロール(この場合はストレージ管理者)に対するメンバーリストを更新します。

既存のメンバーリストは、ここで指定されたリストに置き換えられますが、他のロールに関するポリシー設定は影響を受けません。

先程はポリシー自体を変更しましたが、今回は特定のロールに対するメンバーリストを更新するという操作だと考えていいと思います。(よって中間的な粒度でのポリシーの変更となります)

特定の役割(ロール)に新しいメンバーを追加

resource "google_storage_bucket_iam_member" "member" {
  bucket = google_storage_bucket.default.name
  role = "roles/storage.admin"
  member = "user:jane@example.com"
}

resource google_storage_bucket_iam_member memberの部分は、通常のようにTerraformでリソースを定義する箇所となります。このリソースは、特定のロールに対して単一のメンバーを追加します。

  • bucket
    • 対象のバケット(google_storage_bucket.default.name)を指定します。
  • role
    • 設定するロール(roles/storage.admin)を指定します。この例ではストレージ管理者の役割を設定しています。
  • member
    • このロールを与える単一のメンバーを指定します。(user:jane@example.comを指定)

このリソースは、指定されたバケットのポリシーにおいて、特定のロール(この場合はストレージ管理者)に対して新しいメンバーを追加します。既存のメンバーや他のロールに関するポリシー設定は影響を受けません。

先程はメンバーリストを更新しましたが、今回は特定のロールに対して単一のメンバーを追加するという操作だと考えていいと思います。(よって最も細かい粒度でのポリシーの変更となります)

まとめ

今回は結構ニッチな話になりましたが、IAMポリシーの仕組みを理解していても、コードになった途端依存関係がわからなくなることがあるので、解説しました。(私はわかりづらかった)

今回紹介した3つのIAMポリシー管理リソースは、それぞれ異なる粒度でポリシーを制御できるため、状況に応じて適切なものを選択することが重要かと思います。

全体的なポリシー管理が必要な場合はpolicyを、特定のロールに対するメンバーリストを管理する場合はbindingを、個別のメンバー追加にはmemberを使用すると適切な運用となります。

Googleのベストプラクティスに則って、最小権限の原則を適応させるよう意識していきます。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.