ポリシーについて

Google Cloud リソースのアクセス制御は、リソースに接続された Identity and Access Management(IAM)ポリシーによって管理されます。各リソースに接続できる IAM ポリシーは 1 つだけです。IAM ポリシーは、リソース自体へのアクセスだけでなく、ポリシーを継承する子リソースへのアクセスも制御します。

このページでは、IAM ポリシーを JSON 形式で示します。また、gcloud コマンドライン ツールを使用してポリシーを YAML 形式で取得することもできます。

ポリシーの構造

IAM ポリシーは、ロール バインディングとメタデータから構成されます。ロール バインディングは、リソースに付与するアクセス権を指定します。ロール バインディングでは、1 人以上のメンバーを 1 つの IAM ロールとコンテキスト固有の条件に関連付け(またはバインド)します。この条件により、ロールを付与する方法とタイミングを変更できます。メタデータには、Etag やバージョンなど、ポリシーに関する追加情報を記述します。これにより、ポリシーを簡単に管理できるようになります。

各ロール バインディングには、次のフィールドを含めることができます。

  • メンバー。ID またはプリンシパルともいいます。ユーザー アカウント、サービス アカウント、Google グループ、ドメインなどがメンバーになります。

    各 IAM ポリシーには、最大 1,500 人のメンバーを指定できます。Google グループには、250 人までのメンバーを含めることができます。

    IAM は、ポリシーのバインディング内の各メンバーのすべての出現をカウントします。複数のバインディングに出現するメンバーは重複除去されません。たとえば、メンバー user:alice@example.com が 50 個のバインディングに出現する場合、ポリシーのすべてのバインディングに対して 1,450 人のメンバーを追加できます。

  • ロール。Google Cloud リソースにアクションを実行するための権限をまとめたものです。

  • 条件。リクエストの属性(リクエストの送信元、ターゲット リソースなど)に基づいてロール バインディングをさらに制限する論理式です。条件は通常、アクセスがリクエストされたときのコンテキストに応じて制限を行う場合に使用します。

    条件を含むロール バインディングのことを条件付きロール バインディングといいます。

    一部の Google Cloud サービスは、IAM ポリシーの条件を受け付けません。条件を許可するサービスとリソースタイプのリストについては、条件付きロール バインディングを許可するリソースタイプをご覧ください。

IAM ポリシーのメタデータには次のフィールドが含まれます。

  • etag フィールド。同時制御に使用し、ポリシーが一貫した方法で更新されるようにします。 詳しくは、このページのポリシーでの ETag の使用をご覧ください。
  • version フィールド。特定のポリシーのスキーマ バージョンを指定します。詳しくは、このページのポリシー バージョンをご覧ください。

組織、フォルダ、プロジェクト、請求先アカウントの場合、IAM ポリシーに auditConfig フィールドを含めることもできます。このフィールドは、各サービスの監査ログを生成するアクティビティの種類を指定します。IAM ポリシーのこの部分を構成する方法については、データアクセス監査ログの構成をご覧ください。

通常、IAM ポリシーを更新すると、変更は 60 秒以内に有効になります。ただし、変更が Google Cloud に完全に反映されるまでに最大で 7 分かかる場合があります。

ポリシーでの ETag の使用

複数のシステムが同じ IAM ポリシーに同時に書き込みを行うと、それぞれの変更が上書きされてしまう可能性があります。このリスクは、IAM ポリシーの更新に次のような複数のオペレーションが関係するために発生します。

  1. 既存のポリシーの読み取り
  2. ポリシーの変更
  3. ポリシー全体の書き込み

システム A がポリシーを読み取り、システム B がそのポリシーの更新バージョンをすぐに書き込む場合、システム A はシステム B が行った変更を認識しません。システム A がポリシーに独自の変更を行うと、システム B の変更が失われる可能性があります。

この問題を防ぐため、Identity and Access Management(IAM)では、ポリシーで etag フィールドを使用することで同時実行制御を行うことができます。すべての IAM ポリシーには etag フィールドが含まれています。このフィールドの値は、ポリシーが更新されるたびに変わります。IAM ポリシーに etag フィールドが含まれていて、ロール バインディングがない場合、このポリシーは IAM ロールを付与しません。

etag フィールドには BwUjMhCsNvY= などの値が含まれます。ポリシーを更新する場合は、更新されたポリシーに etag フィールドを含めてください。ポリシーを取得した後に、そのポリシーが変更されている場合、etag が一致しないため、更新に失敗します。REST API の場合、HTTP ステータス コード 409 Conflict が返されます。レスポンスの本文は次のようになります。

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

このエラーが表示された場合は、一連のオペレーションを再試行します。ポリシーを再度読み、必要に応じて修正を行い、更新されたポリシーを書き込んでください。IAM ポリシーの管理に使用するツールで、指数バックオフを使用して再試行を自動的に実行する必要があります。

read-modify-write パターンを使用してポリシーを更新する方法については、アクセス権の付与、変更、取り消しをご覧ください。

例: 単純なポリシー

メンバーをロールにバインドするポリシーについて考えてみましょう。

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

上記の例では、jie@example.com に条件なしでオーナーの基本ロールが付与されています。このロールは、jie@example.com にほぼ無制限のアクセス権を付与します。

例: 複数のロール バインディングを含むポリシー

複数のロール バインディングを含むポリシーについて考えてみましょう。この例では、ロール バインディングごとに異なるロールを付与しています。

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:divya@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

上の例では、最初のロール バインディングで Jie(jie@example.com)に組織管理者の事前定義ロール(roles/resourcemanager.organizationAdmin)が付与されています。このロールには、組織、フォルダ、制限付きプロジェクトのオペレーションに対する権限が含まれています。2 番目のロール バインディングでは、Jie と Divya(divya@example.com)にプロジェクト作成者のロール(roles/resourcemanager.projectCreator)を使用してプロジェクトを作成する権限が付与されます。これらのロール バインディングを組み合わせることで、Jie と Divya の両方にきめ細かいアクセス権を付与でき、Jie には Divya よりも多くのアクセス権が付与されます。

例: 条件付きロール バインディングを含むポリシー

次の IAM ポリシーでは、メンバーを事前定義ロールにバインドし、条件式を使用してロール バインディングを制約しています。

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

この例では、ポリシーに条件式が含まれているため、version フィールドが 3 に設定されています。ポリシー内のバインディングは条件付きロール バインディングです。Google グループ prod-dev@example.com とサービス アカウント prod-dev-example@appspot.gserviceaccount.com に、2022 年 7 月 1 日までを期限としてロールを付与します。

各ポリシー バージョンでサポートされる機能の詳細については、このページのポリシー バージョンをご覧ください。

例: 条件付きロール バインディングと無条件のロール バインディングを含むポリシー

次の IAM ポリシーには、同じロールに対して条件付きと無条件の両方のロール バインディングが含まれています。

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

この例では、サービス アカウント serviceAccount:prod-dev-example@appspot.gserviceaccount.com が同じロールの 2 つのロール バインディングに含まれています。最初のロール バインディングは無条件です。2 番目のロール バインディングは条件付きで、2022 年 7 月 1 日までを期限としてロールを付与します。

このポリシーは常にサービス アカウントにロールを付与します。IAM では、条件付きロール バインディングは条件のないロール バインディングをオーバーライドしません。メンバーがロールにバインドされていて、ロール バインディングに条件がない場合、メンバーは常にそのロールを持ちます。同じロールの条件付きロール バインディングにメンバーを追加しても、効果はありません。

これに対して、Google グループ group:prod-dev@example.com は条件付きロール バインディングにのみ含まれます。したがって、このグループは 2022 年 7 月 1 日までロールが付与されます。

例: 削除されたメンバーにロールをバインドするポリシー

次のポリシーについて考えてみましょう。このポリシーは、ユーザー donald@example.com にロールをバインドしますが、このユーザーのアカウントは削除されています。

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

donald@example.com という名前の新しいユーザーを作成しても、削除されたユーザーのポリシーのロール バインディングは新しいユーザーには適用されません。このため、新しいユーザーは削除されたユーザーに付与されたロールを継承できません。新しいユーザーにロールを付与する場合は、このページの削除されたメンバーを含むポリシーに示すように、新しいユーザーをポリシーのロール バインディングに追加します。

さらに、ユーザー名には接頭辞 deleted: と接尾辞 ?uid=numeric-id が含まれています。numeric-id は削除されたユーザーの一意の数値 ID です。この例では、ポリシーに user:donald@example.com ではなく deleted:user:donald@example.com?uid=123456789012345678901 が示されています。

サービス アカウントとグループはユーザーと同じように動作します。サービス アカウントまたはグループを削除し、削除されたメンバーを含むポリシーを表示すると、削除されたメンバーの名前に接頭辞 deleted: と接尾辞 ?uid=numeric-id が付いています。

デフォルト ポリシー

IAM ポリシーを受け入れるリソースは、デフォルトの IAM ポリシーを使用して作成されます。ほとんどのリソースのデフォルト ポリシーは空です。ただし、一部のリソースのデフォルト ポリシーには、特定のロール バインディングが自動的に含まれます。たとえば、新しいプロジェクトを作成すると、そのプロジェクトの IAM ポリシーには、プロジェクトに対するオーナーロール(roles/owner)を付与するロール バインディングが自動的に付与されます。

これらのロール バインディングはシステムによって作成されます。ロール バインディングを作成するために、リソースに対する getIamPolicy 権限または setIamPolicy 権限は必要としません。

IAM ポリシーでリソースが作成されるかどうかを確認するには、リソースのドキュメントをご覧ください。

ポリシーの継承とリソース階層

Google Cloud のリソースは階層構造になっています。組織ノードが階層のルートノードで、その下に必要に応じてフォルダ、プロジェクトを作成できます。他のほとんどのリソースは、プロジェクトの下で作成され、管理されます。階層内のルートノードを除き、各リソースには 1 つの親が存在します。詳細については、リソース階層のトピックをご覧ください。

IAM ポリシーを設定する際は、リソース階層を考慮する必要があります。組織レベル、フォルダレベル、プロジェクト レベルなど、階層の上位レベルにポリシーを設定する場合、付与されるアクセス スコープには、そのポリシーが接続されるリソースレベルだけでなく、そのレベルより下にあるすべてのリソースも含まれます。たとえば、組織レベルで設定されたポリシーは、組織と組織内のすべてのリソースに適用されます。同様に、プロジェクト レベルで設定されたポリシーは、プロジェクトとプロジェクト内のすべてのリソースに適用されます。

ポリシー継承とは、リソース階層で下位にあるリソースにポリシーがどのように適用されるかを表す用語です。有効なポリシーは、リソースの階層内のすべての親ポリシーがリソースにどのように継承されるかを表す用語です。これは、次のものから構成されます。

  • リソースに設定されているポリシー
  • 階層内でリソースの祖先レベルで設定されているポリシー

リソースの有効なポリシーに影響する新しい役割バインディング(親リソースから継承されたバインディング)は、それぞれ別個に評価されます。上位レベルの役割バインディングのいずれかでリクエストへのアクセスが許可された場合、リソースに対する特定のアクセス リクエストが許可されます。

リソースの継承されたポリシーの任意のレベルに新しい役割バインディングが設定されると、アクセス許可のスコープが広がります。

例: ポリシー継承

ポリシー継承を理解するために、組織レベルで設定されたポリシーについて考えてみましょう。

組織レベルのポリシー

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

ストレージ オブジェクト閲覧者の役割(roles/storage.objectViewer)には、プロジェクトと Cloud Storage オブジェクトに対する get 権限と list 権限が含まれています。この役割バインディングを組織レベルで設定すると、このバインディングは組織の下位レベルに適用されます。つまり、すべてのプロジェクトとそのプロジェクトに含まれるすべての Cloud Storage オブジェクトに適用されます。

ポリシー継承をさらに詳しく説明するため、ポリシーを myproject-123 に設定した場合について見てみましょう。

プロジェクト レベルのポリシー

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

上記の例では、ストレージ オブジェクト作成者のロール(roles/storage.objectCreator)を Divya に付与し、myproject-123 での Cloud Storage オブジェクトの作成を許可しています。これで、myproject-123 の下にある Cloud Storage オブジェクトに対するアクセス権を Divya に付与するロール バインディングが 2 つになりました。次のポリシーが適用されます。

  • 組織レベルのポリシーにより、この組織内に存在する Cloud Storage オブジェクトの一覧を取得できます。
  • プロジェクト レベルでは、プロジェクト myproject-123 に対してそのプロジェクト内でオブジェクトを作成する権限が付与されます。

以下の表に、Divya に有効なポリシーを示します。

組織レベルで storage.objectViewer ロールによって付与される権限 myproject-123 の storage.objectCreator ロールによって付与される権限 myproject-123 で Divya に有効なスコープ
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.create
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
storage.objects.create

ポリシー バージョン

IAM には時間とともに新しい機能が追加されていきます。それに伴い、ポリシー スキーマのフィールドが大幅に追加または変更される可能性があります。ポリシー構造の一貫性を前提としている既存の連携を維持するため、こうした変更は新しいポリシー スキーマ バージョンで行われます。

IAM と初めて連携する場合は、その時点で最新のポリシー スキーマ バージョンを使用することをおすすめします。以下では、使用可能なバージョンと各バージョンの使い方について説明します。また、目的のバージョンを指定する方法やトラブルシューティングのシナリオについても紹介します。

既存のすべての IAM ポリシーでは、ポリシー メタデータの一部として version フィールドを指定します。ここでは、以下で強調表示されている部分について考えてみます。

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

このフィールドには、ポリシーの構文スキーマのバージョンを指定します。ポリシーの各バージョンには、ロール バインディングで使用できる特定の構文スキーマが含まれています。新しいバージョンには、以前のバージョンでサポートされていない新しい構文スキーマのロール バインディングが含まれていることがあります。このフィールドは、ポリシー構文スキーマの制御目的以外で使用することはありません。

有効なポリシー バージョン

IAM ポリシーでは、次のポリシー バージョンを使用できます。

バージョン 説明
1 ポリシー用の IAM 構文スキーマの最初のバージョン。1 人以上のメンバーに 1 つのロールをバインディングできます。条件付きロール バインディングはサポートされていません。
2 内部用に予約されています。
3 ロール バインディングに condition フィールドを追加し、コンテキスト ベースのルールと属性ベースのルールでロール バインディングを制限します。詳細については、IAM Conditions の概要をご覧ください。

ポリシーの取得時にポリシー バージョンを指定する

REST API とクライアント ライブラリでは、IAM ポリシーを取得する際に、リクエストでポリシー バージョンを指定することをおすすめします。リクエストでポリシー バージョンが指定されている場合、IAM は呼び出し元がそのポリシー バージョンの機能を認識し、正しく処理できるとみなします。

リクエストでポリシー バージョンが指定されていない場合、IAM は呼び出し元がバージョン 1 ポリシーを要求しているとみなします。

ポリシーを取得すると、IAM はリクエストのポリシー バージョンを確認します。リクエストでバージョンを指定していない場合はデフォルト バージョンを確認します。IAM は、バージョン 1 ポリシーでサポートされていないフィールドのポリシーもチェックします。この情報を使用して、送信するレスポンスのタイプを決定します。

  • ポリシーに条件が含まれていない場合、リクエストのバージョン番号に関係なく、IAM は常にバージョン 1 ポリシーを返します。
  • ポリシーに条件があり、呼び出し元がバージョン 3 ポリシーをリクエストした場合、IAM は、その条件を含むバージョン 3 ポリシーを返します。例については、このページのシナリオ 1 をご覧ください。
  • ポリシーに条件があり、呼び出し元がバージョン 1 ポリシーをリクエストした場合、またはバージョンを指定しなかった場合、IAM は、バージョン 1 ポリシーを返します。

    条件を含むロール バインディングの場合、IAM は、文字列 _withcond_、続けてハッシュ値(例: roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8)をロール名に付加します。条件自体は存在しません。例については、このページのシナリオ 2 をご覧ください。

この動作により、条件付きロール バインディングを認識しない古いクライアント ライブラリの問題を回避できます。詳細については、このページのポリシー バージョンのクライアント ライブラリ サポートをご覧ください。

シナリオ 1: IAM Conditions を完全にサポートするポリシー バージョン

次の REST API メソッドを呼び出して、プロジェクトの IAM ポリシーを取得するとします。

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

リクエスト本文には次のテキストが含まれます。

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

レスポンスには、プロジェクトの IAM ポリシーが含まれます。ポリシーに少なくとも 1 つの条件付きロール バインディングが含まれている場合、version フィールドが 3 に設定されています。

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

ポリシーに条件付きロール バインディングが含まれていない場合、リクエストでバージョン 3 が指定されていても、version フィールドは 1 に設定されています。

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

シナリオ 2: IAM Conditions が制限付きでサポートされているポリシー バージョン

次の REST API メソッドを呼び出して、プロジェクトの IAM ポリシーを取得するとします。

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

リクエストの本文は空です。バージョン番号は指定されていません。その結果、IAM はデフォルトのポリシー バージョン 1 を使用します。

ポリシーには、条件付きロール バインディングが含まれています。ポリシー バージョンが 1 であるため、レスポンスには条件が表示されません。ロール バインディングが条件を使用することを示すために、IAM は文字列 _withcond_ をロール名に追加し、その後にハッシュ値を追加します。

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

ポリシーの設定時にポリシー バージョンを指定する

IAM ポリシーを設定する場合、ポリシー バージョンをリクエストで指定することをおすすめします。リクエストでポリシー バージョンが指定されている場合、IAM は呼び出し元がそのポリシー バージョンの機能を認識し、正しく処理できるとみなします。

リクエストでポリシーのバージョンが指定されていない場合、IAM ではバージョン 1 ポリシーに含まれるフィールドのみが許可されます。バージョン 1 ポリシーの条件付きロール バインディングを変更しないことをおすすめします。各ロール バインディングの条件がポリシーで示されていないため、バインドが実際に付与されるタイミングや場所がわかりません。代わりに、各ロール バインディングの条件を示す、ポリシーのバージョン 3 リプレゼンテーションを取得します。そして、そのリプレゼンテーションを使用して、ロール バインディングを更新します。

シナリオ: リクエストとレスポンスのポリシー バージョン

REST API を使用して IAM ポリシーを取得し、リクエストにバージョン 3 を指定したとします。レスポンスには、バージョン 3 を使用する次のポリシーが含まれます。

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

divya@example.com には平日だけでなく週 7 日間のストレージ管理者のロール(roles/storage.admin)が与えられると指定します。ロール バインディングから条件を削除し、REST API リクエストを送信してポリシーを設定します。再度、リクエストでバージョン 3 を指定します。

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

レスポンスには、更新されたポリシーが含まれます。

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

レスポンスのポリシーでは、リクエストでバージョン 3 が指定されたとしても、バージョン 1 が使用されます。ポリシーでは、バージョン 1 ポリシーでサポートされるフィールドのみが使用されるためです。

ポリシー バージョンのクライアント ライブラリ サポート

Google Cloud の一部のクライアント ライブラリでは、バージョン 1 ポリシーのみがサポートされています。クライアント ライブラリが新しいポリシー バージョンに対応していない場合は、新しいバージョンでのみ使用できる機能は使用できません。たとえば、IAM Conditions では、ポリシー バージョン 3 のサポートが必要です。

IAM Conditions など、バージョン 1 ポリシーで使用できない IAM 機能を使用する場合、そのポリシー バージョンをサポートするクライアント ライブラリを使用し、それをリクエストに正しく設定します。

ポリシー バージョン 3 をサポートする IAM の Google API クライアント ライブラリは、次のとおりです。

言語 ポリシー バージョン 3 をサポートするバージョン
C# Google.Apis(v1.41.1 以降)
Go google-api-go-client(v0.10.0 以降)
Java
Node.js googleapis(v43.0.0 以降)
PHP google/apiclient(v2.4.0 以降)
Python google-api-python-client(v1.7.11 以降)
Ruby google-api-client(v0.31.0 以降)

これらのクライアント ライブラリを使用して、次のサービスのリソースでバージョン 3 IAM ポリシーを管理できます。

  • IAM
  • Cloud KMS
  • Cloud Storage
  • Compute Engine
  • Resource Manager

Google Cloud クライアント ライブラリなど、その他のクライアント ライブラリでは、バージョン 1 ポリシーのみがサポートされています。

ポリシー バージョンの gcloud サポート

gcloud ツールで、バージョン 3 IAM ポリシーを管理できます。最新バージョンに更新するには、gcloud components update を実行します。

削除されたメンバーを含むポリシー

ポリシーのロール バインディングに削除されたメンバーが含まれているときに、同じ名前の新しいメンバーにロール バインディングを追加した場合、バインディングは常に新しいメンバーに適用されます。

たとえば、削除されたユーザー donald@example.com と削除されたサービス アカウント my-service-account@project-id.iam.gserviceaccount.com へのロール バインディングを含むポリシーについて考えてみます。

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

donald@example.com という名前の新しいユーザーを作成してプロジェクト作成者のロール(roles/resourcemanager.projectCreator)にバインドすると、そのユーザーは Google Cloud プロジェクトを作成できるようになります。新しいユーザーをバインドするには、次の例のようにポリシーを更新します。

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

IAM ポリシーの監査を簡単にするために、削除されたユーザーをオーナーのロールにバインドされているロールから削除することもできます。

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

ポリシーのベスト プラクティス

次のベスト プラクティスは Google Cloud のユーザー数が多い組織を対象にしたものです。

  • 複数のユーザー アカウントを同じアクセス構成で管理する場合は、Google グループを使用します。個々のユーザー アカウントをグループに追加し、個々のユーザー アカウントではなくグループに目的の役割を付与します。

  • 組織レベルで付与される権限: 組織レベルでアクセス権を付与するメンバーを慎重に検討します。ほとんどの組織では、特定のチーム(セキュリティ チームやネットワーク チームなど)にのみ、このレベルのリソース階層へのアクセス権を付与する必要があります。

  • フォルダレベルで付与される権限: 組織の運用体制を反映させることを検討してください。フォルダ階層を使用して、それぞれの親/子フォルダを別々のセットにまとめ、業務上または運用上のニーズに合わせてアクセス権を付与します。たとえば、親フォルダに部門を割り当て、その子フォルダの 1 つにグループによるリソース アクセスとオペレーションをまとめます。さらに、別の子フォルダに小規模なチームを割り当てます。この 2 つのフォルダには、チームの運用上の要件に合わせてプロジェクトを入れることができます。このようにフォルダを使用すると、親フォルダや組織から継承したポリシーを遵守しながら、アクセス権の分離を適切に行うことができます。Google Cloud リソースの作成や管理を行うときに、ポリシーのメンテナンス作業が少なくなります。

  • プロジェクト レベルで付与される権限: 特定のグループまたは個々の詳細な権限で必要な場合にのみ、プロジェクト レベルで役割バインディングを付与します。特に、プロジェクトの数が多い場合は、管理作業を省力化するため、できる限りフォルダ単位でポリシーを設定することをおすすめします。

次のステップ