ポリシーについて

Google Cloud リソースのアクセス制御は、IAM ポリシーによって管理されます。IAM ポリシーはリソースに関連付けられます。このポリシーは、そのリソース自体へのアクセスだけでなく、ポリシーの継承により、子リソースへのアクセスも管理します。

このトピックでは、JSON 形式の IAM ポリシーについて説明しますが、YAML 形式のポリシーもサポートされます。

ポリシーの構造

ポリシーは、バインディング、監査構成、メタデータから構成されます。バインディングでは、リソースへのアクセス権を付与する方法を指定します。1 つ以上のメンバーを 1 つの役割に関連付けて(バインディング)、コンテキスト固有の条件を適用します。これにより、役割を付与する方法とタイミングを変更できます。AuditConfig フィールドには、アクセス監査の構成データを指定します。メタデータには、Etag バージョンなど、ポリシーに関する追加情報を記述します。これにより、ポリシーを簡単に管理できるようになります。以下では、これらの各部分について説明します。

  • バインディングのリスト。各バインディングには次のフィールドがあります。
    • メンバー。ID またはプリンシパルともいいます。ユーザー アカウント、サービス アカウント、Google グループ、ドメインなどがメンバーになります。
    • 役割。Google Cloud リソースにアクションを実行するための権限をまとめたものです。
    • 条件。リクエストの属性(リクエストの送信元、ターゲット リソースなど)に基づいてロールのバインディングをさらに制限する論理式です。条件は通常、アクセスがリクエストされたときのコンテキストに応じて制限を行う場合に使用します。
  • AuditConfig フィールド。ポリシーの監査ロギングを構成するときに使用します。
  • メタデータ。次のフィールドがあります。
    • etag フィールド。同時制御に使用し、ポリシーが一貫した方法で更新されるようにします。
    • version フィールド。特定のポリシーのスキーマ バージョンを指定します。version フィールドの使用方法については、ポリシー バージョンで詳しく説明します。

IAM ポリシーでのロールのバインディングは、ロールとメンバーリストの組み合わせで行います。条件を含むロール バインディングのことを条件付きのロール バインディングといいます。

ポリシーでの ETag の使用

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

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

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

この問題を防ぐため、Identity and Access Management(IAM)では、ポリシーで etag フィールドを使用することで同時実行制御を行うことができます。このフィールドの値は、ポリシーが更新されるたびに変わります。

ポリシーを更新する必要がある場合は、更新後のポリシーを書き込むときに 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 に条件なしでオーナーの基本役割が付与されています。多くの場合、基本役割にバインドすると必要以上の権限が付与されます。この例では、オーナーの役割に 1,000 を超える権限が含まれています。基本の役割ではなく、事前定義の役割またはカスタム役割を付与することをおすすめします。これらの役割タイプは、スコープと権限の数が制限されています。

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

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

{
  "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 の両方にきめ細かなアクセス権を付与しています。Divya には Jie のアクセス権のサブセットが付与されます。

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

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

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

この例では、ポリシーに条件式が含まれているため、version フィールドが 3 に設定されています。ポリシー内のバインディングは、条件付きロール バインディングです。Google グループ prod-dev@example.com とサービス アカウント prod-dev-example@appspot.gserviceaccount.com に、2020 年 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_2020",
        "description": "Expires on July 1, 2020",
        "expression":
          "request.time < timestamp('2020-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

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

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

これに対して、Google グループ group:prod-dev@example.com は条件付きロール バインディングにのみ含まれます。したがって、このグループは 2020 年 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 が付いています。

この例では、ポリシーが同じ名前の削除済みユーザーにすでにバインドされているため、新しいユーザー donald@example.com をポリシーのバインディングに追加することはできません。この問題を解決する方法については、削除されたメンバーを含むポリシーの手順をご覧ください。

ポリシーの制限

IAM ポリシーには次のような制限があります。

  • リソース階層のレベルで IAM ポリシーをサポートする Google Cloud リソースに複数のポリシーを指定することはできません。こうしたリソースとしては、組織、フォルダ、プロジェクト、個々のリソース(Compute Engine ディスク、イメージなど)があります。
  • 各 IAM ポリシーには、最大 1,500 人の members を指定できます。Google グループには、250 人までのメンバーを含めることができます。

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

  • 通常、setIamPolicy() を呼び出すか、Cloud Console でロール バインディングを更新してから 60 秒以内にポリシーの変更が有効になります。ただし、ポリシーの変更がシステム全体に反映されるまでに 7 分ほどかかる場合があります。

  • 現在、一部の Google Cloud サービスは、リソースの名前、タイプ、Google Cloud を条件付きロール バインディングで使用できる場合でも、リソースレベル ポリシーの条件付きロール バインディングをサポートしていません。たとえば、場合によっては、サービスのリソースへのアクセスを制限する条件付きロール バインディングを含むポリシーをプロジェクトに設定できても、リソース自体には設定できないことがあります。詳細については、IAM Conditions 属性のリファレンスをご覧ください。

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

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_2020",
          "description": "Expires on July 1, 2020",
          "expression": "request.time < timestamp('2020-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 ツールを使用して IAM ポリシーを管理する場合は、バージョン 263.0.0 以降を使用してください。それ以前のバージョンは、バージョン 1 ポリシーのみをサポートしています。

gcloud ツールのバージョン番号を確認するには、gcloud version を実行します。最新バージョンに更新するには、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
}

更新されたポリシーを取得すると、バインディングは新しいユーザーではなく、削除されたユーザーを参照します。

{
  "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": [
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwWWK2TI-5A=",
  "version": 1
}

同様に、my-service-account@project-id.iam.gserviceaccount.com という名前の新しいサービス アカウントを作成した場合、そのサービス アカウントをポリシーのバインディングに追加することはできません。同じ制限が他のタイプのメンバーにも適用されます。

この問題を解決するには、次のいずれかの変更を行います。

  • 可能であれば、削除されたメンバーの削除を取り消します。削除されたメンバーがバインディングにあり、そのメンバーの削除を取り消すことができる場合、メンバーはバインディングに含まれるロールを自動的に取得します。メンバーのロールを手動で復元する必要はありません。

    G Suite ユーザーの削除を取り消すには、最近削除したユーザーを復元するをご覧ください。

    サービス アカウントの削除を取り消すには、サービス アカウントの削除の取り消しをご覧ください。

  • 次のようにポリシーを変更します。

    1. ポリシーによって削除済みメンバーにバインドされるすべてのロールを取り消します。削除されたメンバーがポリシーの複数のバインディングにある場合、削除されたメンバーを各バインディングから削除する必要があります。

      削除されたメンバーを他のポリシーのバインディングから削除する必要はありません。

    2. 新しいメンバーに適切なロールを付与します。

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

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

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

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

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

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

次のステップ