リソース ロケーションの制限

概要

このガイドでは、リソース ロケーションの制約を含む組織のポリシーの設定方法について説明します。

組織のポリシー サービスのリソース ロケーションの制約を使用して、新しいリソースの物理的な場所を制限できます。サービスがリソースを配置、維持する場所は、リソースのロケーション プロパティで特定できます。Google Cloud サービスによってはデータを含むリソースもありますが、そのデータの格納場所もこのプロパティで示されます。この制約を使用することで、階層内でサポートされるサービスのリソースを作成できる場所を Google Cloud 上に定義できます。

リソース ロケーションを定義すると、その制限は新しく作成されたリソースにのみ適用されます。リソース ロケーションの制約を設定する前に作成されたリソースは引き続き存在し、機能し続けます。

この制約を含むポリシーは、Cloud Storage や Dataproc などの特定のサービスのサブリソース作成には適用されません。

制限事項

リソース ロケーションの組織のポリシー サービスの制約により、ロケーションを選択できるリソースの作成機能を制御します。この制約は、Compute Engine グローバル アドレスなどのグローバル リソースや、ロケーションの選択をサポートしていないリソースが作成される場所には影響しません。

稼働中の既存のインフラストラクチャの破損を防ぐには、本番環境以外のプロジェクトとフォルダで新しいポリシーをテストしてから、組織内で段階的にポリシーを適用してください。

データ ストレージ コミットメントについては、Google Cloud 利用規約とサービス固有の規約をご覧ください。リソース ロケーションの制約を含む組織のポリシーは、データ ストレージ コミットメントではありません。

この制約は、プロダクトとリソースタイプの特定のサブセットに適用されます。サポートされているサービスと各サービスの動作の詳細については、リソース ロケーションのサポート対象サービスページをご覧ください。

ロケーション タイプ

Google Cloud リソースは、さまざまなサイズ分類のロケーション タイプでデプロイできます。最も規模の大きなロケーション タイプは、複数の region を含む multi-region です。各 region はさらに zones に分けられます。リージョンとゾーンの詳細については、リージョンとゾーンの概要をご覧ください。

• Multi-region ロケーションは、複数の region の物理リソースによって裏付けられ、通常は、ストレージ ベースのリソースによってのみ使用されます。たとえば、us、asia、europe、global などです。

• Region ロケーションは、互いに地理的に離れた場所にあります。たとえば、us-west1（オレゴン）、asia-northeast1（東京）、europe-west1（ベルギー）などです。

• Zone ロケーションは、リソースをデプロイするために使われる最も細かく分離されたロケーション タイプです。zone は、region 内の独立した障害発生ドメインです。たとえば、us-east1-b、us-west1-b、asia-northeast1-a などです。

ロケーションを設定するときは、in: 接頭辞と値グループを使用する必要があります。Google Cloud でキュレートされた値グループを使用すると、現在または将来の Cloud のロケーションを指定せずに、地理的なロケーションを選択できます。

値グループの in: 接頭辞は、値グループ内に存在するすべての値がポリシーの一部と見なされるように指定します。接頭辞なしでグループ値または Google Cloud リージョンを入力すると、以下のルールに従って、in: 接頭辞が自動的に追加されます。

• in: 接頭辞を使用するロケーションを入力し、そこに無効なグループが含まれている場合、ポリシーの変更は失敗します。
• us-east1 などのリージョンであるロケーションを入力すると、この例では in:us-east1-locations の前に in: 接頭辞が付加されます。
• us-locations などのリージョンまたはマルチリージョン値グループを入力すると、この例では in:us-locations の前に in: 接頭辞が付加されます。
• us-east1-b や us などのゾーンまたはマルチリージョンを入力した場合、値は変更されません。

組織のポリシーの設定

リソース ロケーションの制約は、リスト型制約の一種です。リソース ロケーション制約の allowed_values リストまたは denied_values リストに対して、ロケーションの追加または削除を行えます。新しいロケーションが使用可能リストに追加されたときに、組織のポリシーによってサービスの動作が予期せず制限されてしまうのを回避するには、値グループ、または定義する地理的境界全体を表す allowed_values のリストを使用してください。

リソース ロケーションの制約を含む組織のポリシーを設定するには:

name: organizations/ORGANIZATION_ID/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      deniedValues:
      - in:us-east1-locations
      - in:northamerica-northeast1-locations

gcloud org-policies set-policy POLICY_PATH

name: organizations/01234567890/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:us-east1-locations
      - in:northamerica-northeast1-locations

curl -X POST -H "Content-Type: application/json" -H "Authorization: \
Bearer ${bearer_token}" -d '{policy: {etag: "BwVtXec438Y=", constraint: \
"constraints/gcp.resourceLocations", list_policy: {denied_values: \
["in:europe-locations", "in:southamerica-locations"] }}}' \
https://cloudresourcemanager.googleapis.com/v1/organizations/123456789:setOrgPolicy

name: organizations/01234567890/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      deniedValues:
      - in:europe-locations
      - in:southamerica-locations

組織のポリシーで制約を使用する方法については、制約の使用をご覧ください。

組織のポリシーでの継承の使用

リソースの親ノードから組織のポリシーを継承するように、組織のポリシーを調整できます。継承を使用すると、リソース階層全体で使われる組織のポリシーをきめ細かく制御できます。

リソースノードで継承を有効にするには、組織のポリシー YAML ファイルで inheritFromParent = true を設定します。例:

name: organizations/01234567890/policies/gcp.resourceLocations
spec:
  inheritFromParent: true
  rules:
  - values:
      deniedValues:
      - in:us-west1

エラー メッセージの例

リソース ロケーションの制約をサポートするサービスでは、制約に違反する場所に新しいリソースを作成することはできません。サービスが、制約に違反する場所にリソースを作成しようとすると、エラーが発生し、エラー メッセージが生成されます。

このエラー メッセージの形式は次のようになります。LOCATION_IN_REQUEST violates constraint constraints/gcp.resourceLocations on the resource RESOURCE_TESTED.

次の例では、ポリシーの適用が原因で、Compute Engine リソースが新しいインスタンスを作成できません。

Location ZONE:us-east1-b violates constraint constraints/gcp.resourceLocations
on the resource
projects/policy-violation-test/zones/us-east1-b/instances/instance-3.

Google Cloud Observability と Cloud Audit Logs のログエントリ:

{
 insertId: "5u759gdngec"
 logName: "projects/policy-violation-test/logs/cloudaudit.googleapis.com%2Factivity"
 protoPayload: {
  @type: "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {…}
  authorizationInfo: [6]
  methodName: "beta.compute.instances.insert"
  request: {…}
  requestMetadata: {…}
  resourceLocation: {…}
  resourceName: "projects/policy-violation-test/zones/us-east1-b/instances/instance-3"
  response: {
   @type: "type.googleapis.com/error"
   error: {
    code: 412
    errors: [
     0: {
      domain: "global"
      location: "If-Match"
      locationType: "header"
      message: "Location ZONE:us-east1-b violates constraint constraints/gcp.resourceLocations on the resource projects/policy-violation-test/zones/us-east1-b/instances/instance-3."
      reason: "conditionNotMet"
     }
    ]
    message: "Location ZONE:us-east1-b violates constraint constraints/gcp.resourceLocations on the resource projects/policy-violation-test/zones/us-east1-b/instances/instance-3."
   }
  }
  serviceName: "compute.googleapis.com"
  status: {
   code: 3
   message: "INVALID_ARGUMENT"
  }
 }
 receiveTimestamp: "2019-06-14T03:04:23.660988360Z"
 resource: {
  labels: {…}
  type: "gce_instance"
 }
 severity: "ERROR"
 timestamp: "2019-06-14T03:04:22.783Z"
}

脆弱性の検出と修正

リソース ロケーションが制約されると、実行時のリソースの作成が制限されます。この機能は、ロケーション違反を防止するのに役立ちますが、既存の違反を特定または修正するものではありません。Security Command Center の組み込みサービスである Security Health Analytics を使用すると、リソース階層のロケーション違反を特定できます。詳細については、組織のポリシーの脆弱性の検出をご覧ください。

Security Health Analytics によるロケーション違反の検出結果がある場合は、Security Health Analytics の検出結果の修正で、検出結果の修正手順を確認してください。

値グループ

値グループは、リソース ロケーションを簡単に定義できるようにするために Google によってキュレートされた、グループとロケーションからなるコレクションです。値グループには多数の関連ロケーションが含まれ、時間の経過とともに Google によって拡張されるので、新しいロケーションに対応するように組織のポリシーを変更しなくて済みます。

組織のポリシーで値グループを使用するには、エントリの先頭に文字列 in: を付加します。値接頭辞の使用方法については、制約の使用をご覧ください。 組織のポリシーを設定するための呼び出しで、グループ名が検証されます。無効なグループ名を使用すると、ポリシーの設定が失敗します。

次の表に、現時点で使用可能なグループのリストを示します。

認証

組織のポリシー サービスは、API の認証と承認に OAuth 2.0 を使用します。OAuth 2.0 署名なしトークンを取得するには、次のようにします。

1. OAuth 2.0 Playground ページに移動します。

2. スコープのステップ 1 リストで、[Cloud Resource Manager API v2] > [https://www.googleapis.com/auth/cloud-platform] を選択し、[Authorize APIs] をクリックします。

3. 表示された [Google でログイン] ページで、アカウントを選択してログインします。

4. Google Oauth 2.0 Playground にアクセス権を与えるには、表示されたプロンプトで [許可] をクリックします。

5. ステップ 2 で、[Exchange authorization code for tokens] をクリックします。

6. 右側にある [Request / Response] ペインの下部に、アクセス トークン文字列が表示されます。

   {
     "access_token": "ACCESS_TOKEN",
     "token_type": "Bearer",
     "expires_in": 3600
   }
   

   ここで、ACCESS_TOKEN は、API 承認に使用できる OAuth 2.0 署名なしトークン文字列です。