Google Cloud リソースへのアクセス権を付与するには、Identity and Access Management（IAM）ポリシー（許可ポリシー）を使用します。これはリソースに適用されます。各リソースに適用できる許可ポリシーは 1 つだけです。許可ポリシーは、リソース自体へのアクセスだけでなく、許可ポリシーを継承する子リソースへのアクセスも制御します。
このページでは、許可ポリシーを JSON 形式で示します。Google Cloud CLI を使用して、YAML 形式の許可ポリシーを取得することもできます。
ポリシーの構造
許可ポリシーは、ロール バインディングとメタデータから構成されます。ロール バインディングは、リソースに付与するアクセス権を指定します。ロール バインディングでは、1 つ以上のプリンシパルを 1 つの IAM ロールとコンテキスト固有の条件に関連付け（またはバインド）します。この条件により、ロールを付与する方法とタイミングを変更できます。メタデータには、Etag やバージョンなど、許可ポリシーに関する追加情報を記述します。これにより、ポリシーを簡単に管理できるようになります。
各ロール バインディングには、次のフィールドを含めることができます。
- 1 つ以上のプリンシパル。メンバーまたは ID とも呼ばれます。プリンシパルには、ユーザー アカウント、サービス アカウント、Google グループ、ドメインなど、いくつかのタイプがあります。サポートされているプリンシパル タイプの全一覧については、プリンシパル識別子をご覧ください。
- ロール。Google Cloud リソースにアクションを実行するための権限をまとめたものです。
条件。リクエストの属性（リクエストの送信元、ターゲット リソースなど）に基づいてロール バインディングをさらに制限する論理式です。条件は通常、アクセスがリクエストされたときのコンテキストに応じて制限を行う場合に使用します。
条件を含むロール バインディングのことを条件付きロール バインディングといいます。
一部の Google Cloud サービスは、許可ポリシーの条件を受け付けません。条件を許可するサービスとリソースタイプのリストについては、条件付きロール バインディングを許可するリソースタイプをご覧ください。
プリンシパルのアクセス権に対する変更は結果整合性になります。つまり、アクセス権の変更がシステム全体に反映されるまで時間がかかります。アクセス権の変更が伝播されるまでの時間については、アクセス変更の伝播をご覧ください。
すべてのプリンシパルの上限
各許可ポリシーには、最大 1,500 個のプリンシパルを指定できます。この上限においては、IAM は、許可ポリシーがデータアクセス監査ロギングから除外したプリンシパルと、許可ポリシーのロール バインディング内の各プリンシパルのすべての出現をカウントします。複数のロール バインディングに出現するプリンシパルは重複除去されません。たとえば、許可ポリシーにプリンシパル user:sample-user@example.com のロール バインディングのみが含まれ、このプリンシパルが 50 個のロール バインディングにある場合、別の 1,450 個のプリンシパルを許可ポリシーのロール バインディングに追加できます。
また、この上限において、ドメインまたは Google グループは、ドメインまたはグループ内の個々のメンバーの数に関係なく、1 つのプリンシパルとしてカウントされます。
IAM Conditions を使用するか、通常は識別子の長い多くのプリンシパルにロールを付与すると、許可ポリシー内のプリンシパルの数を減らすことができます。
グループとドメインの上限
許可ポリシーのプリンシパルは、Google グループ、Cloud Identity ドメイン、Google Workspace アカウントのいずれか、またはその組み合わせで最大 250 個まで指定できます。
この上限において、Cloud Identity ドメイン、Google Workspace アカウント、Google グループは次のようにカウントされます。
- Google グループの場合、許可ポリシーにグループが出現する回数に関係なく、一意の各グループは 1 回だけカウントされます。これは、許可ポリシーのプリンシパルの総数に対するグループのカウント方法とは異なります。この制限では、グループの出現回数に応じて制限が適用されます。
- Cloud Identity ドメインまたは Google Workspace アカウントの場合、IAM は許可ポリシーのロール バインディング内の各ドメインまたはアカウントのすべての出現をカウントします。複数のロール バインディングに出現するドメインまたはアカウントは重複除去されません。
たとえば、許可ポリシーに 1 つのグループ（group:my-group@example.com）のみが含まれ、そのグループが許可ポリシーに 10 回出現している場合、上限に達するまでにさらに 249 個の Cloud Identity ドメイン、Google Workspace アカウント、一意のグループを追加できます。
また、許可ポリシーに 1 つのドメイン（domain:example.com）のみが含まれていて、そのドメインが許可ポリシーに 10 回出現している場合、上限に達するまでにさらに 240 個の Cloud Identity ドメイン、Google Workspace アカウント、または一意のグループを追加できます。
ポリシー メタデータ
許可ポリシーのメタデータには次のフィールドが含まれます。
etagフィールド。同時制御に使用し、許可ポリシーが一貫した方法で更新されるようにします。詳しくは、このページのポリシーでの ETag の使用をご覧ください。versionフィールド。特定の許可ポリシーのスキーマ バージョンを指定します。詳しくは、このページのポリシー バージョンをご覧ください。
組織、フォルダ、プロジェクト、請求先アカウントの場合、許可ポリシーに auditConfig フィールドを含めることもできます。このフィールドは、各サービスの監査ログを生成するアクティビティの種類を指定します。許可ポリシーのこの部分を構成する方法については、データアクセス監査ログの構成をご覧ください。
ポリシーでの ETag の使用
複数のシステムが同じ許可ポリシーに同時に書き込みを行うと、それぞれの変更が上書きされてしまう可能性があります。このリスクは、複数のオペレーションを含む読み取り - 変更 - 書き込みパターンを使用して許可ポリシーが更新されるために発生します。
- 既存の許可ポリシーの読み取り
- 許可ポリシーの変更
- 許可ポリシー全体の書き込み
システム A が許可ポリシーを読み取り、システム B がその許可ポリシーの更新バージョンを直ちに書き込む場合、システム A はシステム B が行った変更を認識しません。システム A が許可ポリシーに独自の変更を行うと、システム B の変更が失われる可能性があります。
この問題を回避するため、Identity and Access Management（IAM）では、許可ポリシーで etag フィールドを使用することで同時実行制御を行うことができます。すべての許可ポリシーには etag フィールドが含まれ、このフィールドの値は許可ポリシーが更新されるたびに変化します。許可ポリシーに 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"
}
}
このエラーが表示された場合は、一連のオペレーションを再試行します。許可ポリシーを再度読み、必要に応じて修正を行い、更新された許可ポリシーを書き込んでください。許可ポリシーの管理に使用するツールで、指数バックオフを使用して再試行を自動的に実行する必要があります。
例: 単純なポリシー
プリンシパルをロールにバインドする許可ポリシーについて考えてみましょう。
{
"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:raha@example.com",
"user:jie@example.com"
],
"role": "roles/resourcemanager.projectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
上の例では、最初のロール バインディングで Jie（jie@example.com）に組織管理者の事前定義ロール（roles/resourcemanager.organizationAdmin）が付与されています。このロールには、組織、フォルダ、制限付きプロジェクトのオペレーションに対する権限が含まれています。2 番目のロール バインディングでは、Jie と Raha（raha@example.com）にプロジェクト作成者のロール（roles/resourcemanager.projectCreator）を使用してプロジェクトを作成する権限が付与されます。これらのロール バインディングを組み合わせることで、Jie と Raha の両方にきめ細かいアクセス権を付与でき、Jie には Raha よりも多くのアクセス権が付与されます。
例: 条件付きロール バインディングを含むポリシー
次の許可ポリシーでは、プリンシパルを事前定義ロールにバインドし、条件式を使用してロール バインディングを制約しています。
{
"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 日までを期限としてロールを付与します。
各許可ポリシー バージョンでサポートされる機能の詳細については、このページのポリシー バージョンをご覧ください。
例: 条件付きロール バインディングと無条件のロール バインディングを含むポリシー
次の許可ポリシーには、同じロールに対して条件付きと無条件の両方のロール バインディングが含まれています。
{
"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 にロールをバインドしますが、このユーザーのアカウントは削除されています。そのため、ユーザーの識別子には deleted: 接頭辞が付いています。
{
"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 が付いています。
デフォルト ポリシー
許可ポリシーを受け入れるリソースは、すべてデフォルトの許可ポリシーで作成されます。ほとんどのリソースのデフォルトの許可ポリシーは空です。ただし、一部のリソースのデフォルトの許可ポリシーには、特定のロール バインディングが自動的に含まれます。たとえば、新しいプロジェクトを作成すると、そのプロジェクトの許可ポリシーには、プロジェクトに対するオーナーロール（roles/owner）を付与するロール バインディングが自動的に付与されます。
これらのロール バインディングはシステムによって作成されます。ロール バインディングを作成するために、リソースに対する getIamPolicy 権限または setIamPolicy 権限は必要としません。
許可ポリシーでリソースが作成されるかどうかを確認するには、リソースのドキュメントをご覧ください。
ポリシーの継承とリソース階層
Google Cloud のリソースは階層構造になっています。組織ノードが階層のルートノードで、その下に必要に応じてフォルダ、プロジェクトを作成できます。他のほとんどのリソースは、プロジェクトの下で作成され、管理されます。組織を除き、各リソースの親は 1 つのみです。階層のルートノードとなる組織に親はありません。詳細については、リソース階層のトピックをご覧ください。
許可ポリシーを設定する際は、リソース階層を考慮する必要があります。組織レベル、フォルダレベル、プロジェクト レベルなど、階層の上位レベルに許可ポリシーを設定する場合、付与されるアクセス スコープには、その許可ポリシーが接続されるリソースレベルだけでなく、そのレベルより下にあるすべてのリソースも含まれます。たとえば、組織レベルで設定された許可ポリシーは、組織と組織内のすべてのリソースに適用されます。同様に、プロジェクト レベルで設定された許可ポリシーは、プロジェクトとプロジェクト内のすべてのリソースに適用されます。
ポリシー継承とは、リソース階層で下位にあるリソースに許可ポリシーがどのように適用されるかを表す用語です。有効なポリシーは、リソースの階層内のすべての親許可ポリシーがリソースにどのように継承されるかを表す用語です。これは、次のものから構成されます。
- 許可リソースに設定されているポリシー
- 階層内でリソースの祖先レベルで設定されている許可ポリシー
リソースの有効な許可ポリシーに影響する新しいロール バインディング（親リソースから継承されたバインディング）は、それぞれ別個に評価されます。上位レベルのロール バインディングのいずれかでリクエストへのアクセスが許可された場合、リソースに対する特定のアクセス リクエストが許可されます。
リソースの継承された許可ポリシーの任意のレベルに新しいロール バインディングが設定されると、アクセス許可のスコープが広がります。
例: ポリシー継承
許可ポリシーの継承を理解するために、リソース階層で 2 つの異なるレベルで、ユーザー（Raha）に 2 つの異なる IAM ロールを付与してみましょう。
Raha に組織レベルでロールを付与するには、組織で次の許可ポリシーを設定します。
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.objectViewer"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
この許可ポリシーで、Raha にストレージ オブジェクト閲覧者ロール（roles/storage.objectViewer）を付与します。このロールには、プロジェクトと Cloud Storage オブジェクトに対する get 権限と list 権限が含まれています。組織で許可ポリシーが設定されているため、Raha はこれらの権限を組織内のすべてのプロジェクトと Cloud Storage オブジェクトに使用できます。
Raha にプロジェクト レベルでロールを付与するには、プロジェクト myproject-123 に次の許可ポリシーを設定します。
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.objectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
この許可ポリシーで、Cloud Storage オブジェクトの作成を可能にするストレージ オブジェクト作成者のロール（roles/storage.objectCreator）を Raha に付与します。許可ポリシーを myproject-123 で設定したため、Raha は myproject-123 でのみ Cloud Storage オブジェクトを作成できます。
これで、myproject-123 の下にある Cloud Storage オブジェクトに対するアクセス権を Raha に付与するロール バインディングが 2 つになりました。次の許可ポリシーが適用されます。
- 組織レベルの許可ポリシーにより、この組織内に存在する Cloud Storage オブジェクトの一覧を取得できます。
- プロジェクト レベルの許可ポリシーでは、プロジェクト
myproject-123に対してそのプロジェクト内でオブジェクトを作成する権限が付与されます。
以下の表に、Raha に有効なポリシーを示します。
| 組織レベルで storage.objectViewer ロールによって付与される権限 | myproject-123 の storage.objectCreator ロールによって付与される権限 | myproject-123 で Raha に有効なスコープ |
|---|---|---|
| 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 と初めて連携する場合は、その時点で最新の許可ポリシー スキーマ バージョンを使用することをおすすめします。以下では、使用可能なバージョンと各バージョンの使い方について説明します。また、目的のバージョンを指定する方法やトラブルシューティングのシナリオについても紹介します。
既存のすべての許可ポリシーでは、許可ポリシー メタデータの一部として version フィールドを指定します。ここでは、以下で強調表示されている部分について考えてみます。
{ "bindings": [ { "members": [ "user:jie@example.com" ], "role": "roles/owner" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
このフィールドには、許可ポリシーの構文スキーマのバージョンを指定します。許可ポリシーの各バージョンには、ロール バインディングで使用できる特定の構文スキーマが含まれています。新しいバージョンには、以前のバージョンでサポートされていない新しい構文スキーマのロール バインディングが含まれていることがあります。このフィールドは、許可ポリシーの構文スキーマの制御以外の目的で使用するものではありません。
有効なポリシー バージョン
許可ポリシーでは、次の許可ポリシー バージョンを使用できます。
| バージョン | 説明 |
|---|---|
1 |
ポリシー用の IAM 構文スキーマの最初のバージョン。1 つ以上のプリンシパルに 1 つのロールをバインディングできます。条件付きロール バインディングはサポートされていません。 |
2 |
内部用に予約されています。 |
3 |
ロール バインディングに condition フィールドを追加し、コンテキスト ベースのルールと属性ベースのルールでロール バインディングを制限します。詳細については、IAM Conditions の概要をご覧ください。 |
ポリシーの取得時にポリシー バージョンを指定する
REST API とクライアント ライブラリでは、許可ポリシーを取得する際に、リクエストで許可ポリシー バージョンを指定することをおすすめします。リクエストで許可ポリシーのバージョンが指定されている場合、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 メソッドを呼び出して、プロジェクトの許可ポリシーを取得するとします。
POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy
リクエスト本文には次のテキストが含まれます。
{
"options": {
"requestedPolicyVersion": 3
}
}
レスポンスには、プロジェクトの許可ポリシーが含まれます。許可ポリシーに少なくとも 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 メソッドを呼び出して、プロジェクトの許可ポリシーを取得するとします。
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 は、バージョン 1 の許可ポリシーに含まれるフィールドのみを受け入れます。バージョン 1 の許可ポリシーの条件付きロール バインディングを変更しないことをおすすめします。各ロール バインディングの条件が許可ポリシーで示されていないため、バインドが実際に付与されるタイミングや場所がわかりません。代わりに、各ロール バインディングの条件を示す、許可ポリシーのバージョン 3 リプレゼンテーションを取得します。そして、そのリプレゼンテーションを使用して、ロール バインディングを更新します。
シナリオ: リクエストとレスポンスのポリシー バージョン
REST API を使用して許可ポリシーを取得し、リクエストにバージョン 3 を指定したとします。レスポンスには、バージョン 3 を使用する次の許可ポリシーが含まれます。
{
"bindings": [
{
"members": [
"user:raha@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
}raha@example.com には平日だけでなく週 7 日間のストレージ管理者のロール（roles/storage.admin）が与えられると指定します。ロール バインディングから条件を削除し、REST API リクエストを送信して許可ポリシーを設定します。再度、リクエストでバージョン 3 を指定します。
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.admin"
}
],
"etag": "BwUjMhCsNvY=",
"version": 3
}
レスポンスには、更新された許可ポリシーが含まれます。
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.admin"
}
],
"etag": "BwWd8I+ZUAQ=",
"version": 1
}レスポンスの許可ポリシーでは、リクエストでバージョン 3 が指定されたとしても、バージョン 1 が使用されます。これは、許可ポリシーでは、バージョン 1 の許可ポリシーでサポートされるフィールドのみが使用されるためです。
削除されたプリンシパルを含むポリシー
許可ポリシーのロール バインディングに削除されたプリンシパルが含まれているときに、同じ名前の新しいプリンシパルにロール バインディングを追加した場合、バインディングは常に新しいプリンシパルに適用されます。
たとえば、削除されたユーザー donald@example.com と削除されたサービス アカウント my-service-account@project-id.iam.gserviceaccount.com へのロール バインディングを含む許可ポリシーについて考えてみます。その結果、各プリンシパルの識別子には deleted: 接頭辞が付加されます。
{
"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 リソースの作成や管理を行うときに、許可ポリシーのメンテナンス作業量が低減されます。
プロジェクト レベルで付与されるロール: 最小権限の原則に従う必要がある場合は、プロジェクト レベルでロール バインディングを付与します。たとえば、あるプリンシパルがフォルダ内の 10 個のプロジェクトのうち 3 つにアクセスする必要がある場合は、3 つの各プロジェクトに対するアクセス権を個別に付与する必要があります。それに対して、フォルダにロールを付与すると、そのプリンシパルにとって不要な他の 7 つのプロジェクトへのアクセス権も与えられてしまいます。
あるいは、IAM Conditions を使用して、組織レベルまたはフォルダレベル（ただし、フォルダまたはプロジェクトのサブセットに対してのみ）でロールを付与することもできます。
ドメイン内のプリンシパルにのみアクセス権を付与する: 組織のセキュリティを強化するため、ドメイン外のプリンシパルにロールを付与しないでください。このベスト プラクティスを適用するには、
iam.allowedPolicyMemberDomains組織のポリシー制約を適用します。
次のステップ
- ロールの名前に文字列
withcondを含む許可ポリシーをトラブルシューティングする方法について学習する。 - 許可ポリシーのロール バインディングを管理する方法を確認する。
- バージョン
3の許可ポリシーを使用している IAM Conditions の概要を確認する。 - ポリシー インテリジェンス ツールを確認する。このツールを使って許可ポリシーの確認や管理を行い、セキュリティ構成を事前に改善できます。
- Cloud Asset API を使用して許可ポリシーを検索する。
- Cloud Asset API を使用して、有効な許可ポリシーを表示する。