TerraformでGoogle CloudのIAMを管理する際の注意点

G-gen の堂原です。

当記事では、Terraform を用いて Google Cloud (旧称 GCP) の Identity and Access Management (IAM) を管理する際に、注意すべき点について紹介します。

はじめに

改めて、当記事では Terraform を用いて Google Cloud の IAM を管理する際に注意すべき点として、 具体的には google_project_iam_policy、google_project_iam_binding 及び google_project_iam_member の使い分けについて紹介します。

これらは Terraform 公式の Google Cloud 用の Provider に存在するリソースとなります。

Terraform については以下の記事で紹介しています。 blog.g-gen.co.jp

google_xxx_iam の使い分け

本題に入る前に、Google Cloud 用の Provider に存在する、以下の google_xxx_iam という名称のリソースの使い分けについて紹介します。

• google_organization_iam
• google_folder_iam
• google_project_iam
• google_service_account_iam

正確には、これらの後ろに「_policy」や「_binding」、「_member」をくっつけた、 google_organization_iam_policy などがリソースとなります。

これらのリソースは、google_xxx_iam の xxx を操作する権限（ロール）について管理するものとなります。

例えばサービスアカウントを作成するためのリソースである google_service_account で作成したサービスアカウントに、プロジェクトの権限を与えたい場合は、 googe_service_account_iam ではなくgoogle_project_iam を用いることになります。

当記事では、以降は google_project_iam についてのみ記載しますが、考え方はすべて同じとなります。

google_project_iam_xxx の使い分けと注意点

改めて、以下の 3 つの使い分けと使用時の注意点について紹介します。

• google_project_iam_policy
• google_project_iam_binding
• google_project_iam_member

そのために、以下のような表を用います。

サンプルのロール割当

例えばユーザ A には role/browser、role/run.admin 及び role/storage.admin が付与されているといった見方となります。

この状態で、それぞれのリソースを使ってサービスアカウント β に role/storage.admin を付与する場合について確認していきます。

google_project_iam_policy

google_project_iam_policy は指定したプロジェクトのすべてのプリンシパル（ユーザおよびサービスアカウント）のすべてのロールを一括で管理するリソースとなります。

以下のようなリソースをデプロイするとします。

resource "google_project_iam_policy" "test" {
  project = "プロジェクトのID"
  policy_data = data.google_iam_policy.test.policy_data
}

data "google_iam_policy" "test" {
  binding {
    role = "roles/storage.admin"

    members = [
      "サービスアカウントβ"
    ]
  }
}

この場合、影響範囲は以下の図の赤枠となります。

google_project_iam_policy の影響範囲

そのため、デプロイに成功すると、デプロイ後の環境は以下のようになります。

google_project_iam_policy デプロイ後

Terraform でプロジェクトの IAM を一括管理し、外的な変更がない環境であれば 1 つのリソースで完結するので便利ですが、 IAM 権限が別の方法で操作されるような環境であれば大変なことになります。

google_project_iam_binding

google_project_iam_binding は指定したプロジェクトのすべてのプリンシパルの特定のロールを一括で管理するリソースとなります。

以下のようなリソースをデプロイするとします。

resource "google_project_iam_binding" "test" {
  project = "プロジェクトのID"
  role = "roles/storage.admin"
  members = [
    "サービスアカウントβ"
  ]
}

この場合、影響範囲は以下の図の赤枠となります。

google_project_iam_binding の影響範囲

そのため、デプロイに成功すると、デプロイ後の環境は以下のようになります。

google_project_iam_binding デプロイ後

前述の google_project_iam_policy と、後述する google_project_iam_member の中間のような挙動となります。 こちらも Terraform 以外の方法で IAM 管理をしている場合は競合してしまうため、使用の際は気をつける必要があります。

google_project_iam_member

google_project_iam_member は指定したプロジェクトの特定のプリンシパルの特定のロールを一括で管理するリソースとなります。

以下のようなリソースをデプロイするとします。

resource "google_project_iam_member" "test" {
  project = "プロジェクトのID"
  role = "roles/storage.admin"
  member = "サービスアカウントβ"
}

この場合、影響範囲は以下の図の赤枠となります。

google_project_iam_member の影響範囲

そのため、デプロイに成功すると、デプロイ後の環境は以下のようになります。

google_project_iam_member デプロイ後

google_project_iam_member は指定した組合せ以外のロールには影響を与えないため、一番安全なリソースといえます。

ただ、各プリンシバルの各ロールについてリソースを作成する必要があるため、規模が大きいと多くのリソースを作成する必要があります。

堂原 竜希(記事一覧)

クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。

Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。

Follow @ryu_dohara