概要
このガイドでは、リソース ロケーションの制約を含む組織のポリシーの設定方法について説明します。
組織のポリシー サービスのリソース ロケーションの制約を使用して、新しいリソースの物理的な場所を制限できます。サービスがリソースを配置、維持する場所は、リソースのロケーション プロパティで特定できます。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 署名なしトークン文字列です。