概要
このガイドでは、リソース ロケーションの制約を含む組織のポリシーの設定方法について説明します。
組織のポリシー サービスのリソース ロケーションの制約を使用して、新しいリソースの物理的な場所を制限できます。サービスがリソースを配置、維持する場所は、リソースのロケーション プロパティで特定できます。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
のリストを使用してください。
リソース ロケーションの制約を含む組織のポリシーを設定するには:
コンソール
Google Cloud コンソールで、[組織のポリシー] ページに移動します。
プロジェクト選択ツールから、組織のポリシーを設定する組織、フォルダ、またはプロジェクトを選択します。
[Google Cloud Platform - リソース ロケーション制限] 制約を選択して、[ポリシーの詳細] ページを開きます。
[ポリシーを管理] をクリックします。
[ポリシーの編集] ページで、[親のポリシーをオーバーライドする] を選択します。
[ポリシーの適用] で、[置換] を選択します。
[ルールを追加] をクリックします。
[ポリシーの値] で [カスタム] を選択します。
[ポリシーの種類] で、[許可] を選択して許可されたロケーションのリストを作成するか、[拒否] を選択して拒否されたロケーションのリストを作成します。
[ポリシーの値] ボックスで、
in
接頭辞と値グループ ロケーション文字列を入力してから、Enter キーを押します。たとえば、
in:us-locations
やin:us-west1-locations
などです。[新しいポリシーの値] をクリックすると、複数のロケーション文字列を入力できます。ロケーション文字列として特定のゾーン、リージョン、またはマルチリージョン ロケーションも入力できます。利用可能なロケーションの一覧については、リソース ロケーションのサポート対象サービスページをご覧ください。
ポリシーを適用するには、[ポリシーを設定] をクリックします。
gcloud
リソース ロケーションの制約を適用する組織のポリシーを作成するには、制約を参照するポリシー YAML ファイルを作成します。
constraint: constraints/gcp.resourceLocations listPolicy: deniedValues: - in:us-east1-locations - in:northamerica-northeast1-locations
制約を含む組織のポリシーを適用するには、次のコマンドを実行します。
gcloud org-policies set-policy \ --organization 'ORGANIZATION_ID' \ POLICY_PATH
以下を置き換えます。
- ORGANIZATION_ID: 組織 ID(01234567890 など)。
- POLICY_PATH: 組織のポリシーを含む YAML ファイルへのフルパス。
新しい組織のポリシーの結果を含むレスポンスが返されます。
name: organizations/01234567890/policies/gcp.resourceLocations
spec:
rules:
- values:
allowedValues:
- in:us-east1-locations
- in:northamerica-northeast1-locations
ロケーション文字列として特定のゾーン、リージョン、またはマルチリージョン ロケーションも入力できます。利用可能なロケーションの一覧については、リソース ロケーションのサポート対象サービスページをご覧ください。
API
Resource Manager API を使用して、リソースに対する組織のポリシーを設定することができます。認証と承認用の OAuth 2.0 署名なしトークンが必要です。
リソース ロケーションの制約を使用して組織のポリシーを設定するには:
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 オブザーバビリティと 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:
を付加します。値接頭辞の使用方法については、制約の使用をご覧ください。組織のポリシーを設定するための呼び出しでは、グループ名が検証されません。指定されたグループ名が存在しない場合、そのグループ名が後で Google によって作成されない限り、新しい値は有効な組織のポリシーに追加されません。
次の表に、現時点で使用可能なグループのリストを示します。
グループ | 詳細 | 直接メンバー |
---|---|---|
ヨハネスブルグ | ヨハネスブルグ内のすべてのロケーション:in:africa-south1-locations |
値:
|
アジア | アジア内のすべてのロケーション:in:asia-locations |
グループ:
値:
|
台湾 | 台湾内のすべてのロケーション:in:asia-east1-locations |
値:
|
香港 | 香港のすべてのロケーション:in:asia-east2-locations |
値:
|
東京 | 東京内のすべてのロケーション:in:asia-northeast1-locations |
値:
|
大阪 | 大阪内のすべてのロケーション:in:asia-northeast2-locations |
値:
|
ソウル | ソウル内のすべてのロケーション:in:asia-northeast3-locations |
値:
|
ムンバイ | ムンバイ内のすべてのロケーション:in:asia-south1-locations |
値:
|
デリー | デリー内のすべてのロケーション:in:asia-south2-locations |
値:
|
シンガポール | シンガポール内のすべてのロケーション:in:asia-southeast1-locations |
値:
|
ジャカルタ | ジャカルタ内のすべてのロケーション:in:asia-southeast2-locations |
値:
|
ドーハ | ドーハ内のすべてのロケーション:in:me-central1-locations |
値:
|
ダンマーム | ダンマーム内のすべてのロケーション:in:me-central2-locations |
値:
|
イスラエル | イスラエル内のすべてのロケーション:in:me-west1-locations |
値:
|
オーストラリア | オーストラリア内のすべてのロケーション:in:australia-locations |
グループ:
|
シドニー | シドニー内のすべてのロケーション:in:australia-southeast1-locations |
値:
|
メルボルン | メルボルン内のすべてのロケーション:in:australia-southeast2-locations |
値:
|
AWS | AWS のすべてのロケーション:in:aws-locations |
値:
|
Azure | Azure のすべてのロケーション:in:azure-locations |
値:
|
EU | 欧州連合内のすべてのロケーション: in:eu-locations |
グループ:
値:
|
ワルシャワ | ワルシャワ内のすべてのロケーション:in:europe-central2-locations |
値:
|
フィンランド | フィンランド内のすべてのロケーション:in:europe-north1-locations |
値:
|
マドリッド | マドリッド内のすべてのロケーション:in:europe-southwest1-locations |
値:
|
ベルギー | ベルギー内のすべてのロケーション:in:europe-west1-locations |
値:
|
ベルリン | ベルリン内のすべてのロケーション:in:europe-west10-locations |
値:
|
トリノ | トリノ内のすべてのロケーション:in:europe-west12-locations |
値:
|
フランクフルト | フランクフルト内のすべてのロケーション:in:europe-west3-locations |
値:
|
オランダ | オランダ内のすべてのロケーション:in:europe-west4-locations |
値:
|
ミラノ | ミラノ内のすべてのロケーション:in:europe-west8-locations |
値:
|
パリ | パリ内のすべてのロケーション:in:europe-west9-locations |
値:
|
ヨーロッパ | ヨーロッパ内のすべてのロケーション:in:europe-locations |
グループ:
値:
|
ロンドン | ロンドン内のすべてのロケーション:in:europe-west2-locations |
値:
|
チューリッヒ | チューリッヒ内のすべてのロケーション:in:europe-west6-locations |
値:
|
インド | インド内のすべてのロケーション:in:in-locations |
グループ:
|
日本 | 日本国内のすべてのロケーション:in:jp-locations |
グループ:
|
低炭素ロケーション | 二酸化炭素排出量が低いすべてのロケーション:in:low-carbon-locations |
グループ:
|
低炭素 カナダ | 二酸化炭素排出量が低いカナダ内のすべてのロケーション:in:canada-low-carbon-locations |
グループ:
|
モントリオール | モントリオール内のすべてのロケーション:in:northamerica-northeast1-locations |
値:
|
トロント | トロント内のすべてのロケーション:in:northamerica-northeast2-locations |
値:
|
低炭素 欧州連合 | 二酸化炭素排出量が低い EU 内のすべてのロケーション:in:eu-low-carbon-locations |
グループ:
|
低炭素 ヨーロッパ | 二酸化炭素排出量が低いヨーロッパ内のすべてのロケーション:in:europe-low-carbon-locations |
グループ:
|
低炭素 北米 | 二酸化炭素排出量が低い北米内のすべてのロケーション:in:northamerica-low-carbon-locations |
グループ:
|
アイオワ | アイオワ州内のすべてのロケーション:in:us-central1-locations |
値:
|
オレゴン | オレゴン州内のすべてのロケーション:in:us-west1-locations |
値:
|
低炭素 南アメリカ | 二酸化炭素排出量が低い南アメリカ内のすべてのロケーション:in:southamerica-low-carbon-locations |
グループ:
|
サンパウロ | サンパウロ内のすべてのロケーション:in:southamerica-east1-locations |
値:
|
低炭素 米国 | 二酸化炭素排出量が低い米国内のすべてのロケーション:in:us-low-carbon-locations |
グループ:
|
北米 | 北アメリカ内のすべてのロケーション:in:northamerica-locations |
グループ:
値:
|
カナダ | カナダ内のすべてのロケーション。in:canada-locations |
グループ:
値:
|
米国 | 米国内のすべてのロケーション:in:us-locations |
グループ:
値:
|
オクラホマ | オクラホマ州内のすべてのロケーション:in:us-central2-locations |
値:
|
サウスカロライナ | サウスカロライナ州内のすべてのロケーション:in:us-east1-locations |
値:
|
北バージニア | 北バージニア内のすべてのロケーション:in:us-east4-locations |
値:
|
コロンバス | コロンバス内のすべてのロケーション:in:us-east5-locations |
値:
|
ダラス | ダラス内のすべてのロケーション:in:us-south1-locations |
値:
|
ロサンゼルス | ロサンゼルス内のすべてのロケーション:in:us-west2-locations |
値:
|
ソルトレイクシティ | ソルトレイクシティ内のすべてのロケーション:in:us-west3-locations |
値:
|
ラスベガス | ラスベガス内のすべてのロケーション:in:us-west4-locations |
値:
|
南アメリカ | 南アメリカ内のすべてのロケーション:in:southamerica-locations |
グループ:
|
サンティアゴ | サンティアゴ内のすべてのロケーション:in:southamerica-west1-locations |
値:
|
認証
組織のポリシー サービスは、API の認証と承認に OAuth 2.0 を使用します。OAuth 2.0 署名なしトークンを取得するには、次のようにします。
OAuth 2.0 Playground ページに移動します。
スコープのステップ 1 リストで、[Cloud Resource Manager API v2] > [https://www.googleapis.com/auth/cloud-platform] を選択し、[Authorize APIs] をクリックします。
表示された [Google でログイン] ページで、アカウントを選択してログインします。
Google Oauth 2.0 Playground にアクセス権を与えるには、表示されたプロンプトで [許可] をクリックします。
ステップ 2 で、[Exchange authorization code for tokens] をクリックします。
右側にある [Request / Response] ペインの下部に、アクセス トークン文字列が表示されます。
{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600 }
ここで、ACCESS_TOKEN は、API 承認に使用できる OAuth 2.0 署名なしトークン文字列です。