カスタム組織のポリシーの作成と管理

Google Cloud の組織のポリシーを使用すると、組織のリソースをプログラムで一元管理できます。組織ポリシー管理者は組織ポリシーを定義できます。組織ポリシーは制約と呼ばれる一連の制限で、Google Cloud のリソース階層内の Google Cloud リソースやそれらのリソースの子孫に適用されます。組織のポリシーは、組織レベル、フォルダレベル、またはプロジェクト レベルで適用できます。

組織のポリシーは、さまざまな Google Cloud サービスに事前に定義された制約を提供します。ただし、組織のポリシーからより詳細に制御する必要がある場合は、カスタムの組織のポリシーを作成できます。

このページでは、カスタムの組織のポリシーを表示、作成、管理する方法について説明します。カスタムの組織のポリシーは管理者が作成します。これにより、組織のポリシーによって制限される特定のフィールドに対してより詳細かつカスタマイズ可能なコントロールを実施できます。

準備

組織のポリシーと制約が何であるかとどう機能するかの詳細については、組織のポリシーのサービスの概要をご覧ください。

必要なロール

組織のポリシーを管理するために必要な権限を取得するには、組織に対する組織ポリシー管理者roles/orgpolicy.policyAdmin)の IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

この事前定義ロールには、組織のポリシーを管理するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

組織のポリシーを管理するには、次の権限が必要です。

  • orgpolicy.constraints.list
  • orgpolicy.policies.create
  • orgpolicy.policies.delete
  • orgpolicy.policies.list
  • orgpolicy.policies.update
  • orgpolicy.policy.get
  • orgpolicy.policy.set

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

カスタム制約

カスタム制約は、制約の対象となるリソース、メソッド、条件、アクションを指定する YAML ファイルで作成されます。これらは、組織のポリシーを適用するサービスに固有のものです。カスタム制約の条件は、Common Expression Language(CEL)を使用して定義されます。

カスタム制約を設定する

カスタム制約を作成し、Google Cloud コンソールまたは Google Cloud CLI を使用して組織のポリシーで使用するように設定できます。

Console

  1. Google Cloud コンソールで、[組織のポリシー] ページに移動します。

    [組織のポリシー] に移動

  2. ページの上部にあるプロジェクト選択ツールを選択します。

  3. プロジェクト選択ツールから、組織のポリシーを設定するリソースを選択します。

  4. [ カスタム制約] をクリックします。

  5. [表示名] ボックスに制約の名前を入力します。わかりやすい名前を入力してください。このフィールドの最大長は 200 文字です。エラー メッセージで漏えいする可能性があるため、表示名には PII や機密データを使用しないでください。

  6. [制約 ID] ボックスに、新しいカスタム制約の名前を入力します。カスタム制約は custom. で始まる必要があり、大文字、小文字、数字のみを含めることができます(例: custom.disableGkeAutoUpgrade)。このフィールドの最大長は 70 文字です。接頭辞はカウントされません(例: organizations/123456789/customConstraints/custom.)。 エラー メッセージで漏えいする可能性があるため、制約 ID には PII や機密データを含めないでください。

  7. [説明] ボックスに、ポリシー違反が発生したときにエラー メッセージとして表示される制約の説明を入力します。わかりやすい説明を入力してください。このフィールドの最大長は 2,000 文字です。 エラー メッセージで漏えいする可能性があるため、説明には PII や機密データを含めないでください。

  8. [リソースの種類] ボックスで、制限するオブジェクトとフィールドを含む Google Cloud REST リソースの名前を選択します(container.googleapis.com/NodePool など)。リソースタイプごとに最大 20 個のカスタム制約があります。すでに 20 個のカスタム制約があるリソースタイプに対してカスタム制約を作成しようとすると、オペレーションは失敗します。

  9. [適用方法] で、REST CREATE メソッドに制約を適用するのか、または CREATE メソッドと UPDATE メソッドの両方に制約を適用するのかを選択します。すべての Google Cloud サービスが両方のメソッドをサポートしているわけではありません。各サービスでサポートされているメソッドを確認するには、サポートされているサービスをご覧ください。

  10. 条件を定義するには、[ 条件を編集] をクリックします。

    1. [条件を追加] パネルで、サポートされているサービス リソースを参照する CEL 条件を作成します(例: resource.management.autoUpgrade == false)。このフィールドの最大長は 1000 文字です。CEL の使用方法の詳細については、Common Expression Language をご覧ください。カスタム制約で使用できるサービス リソースの詳細については、カスタム制約でサポートされているサービスをご覧ください。

    2. [保存] をクリックします。

  11. [アクション] で、上記の条件が満たされた場合に評価された方法を許可するか拒否するかを選択します。

    拒否アクションは、条件が true と評価された場合に、リソースを作成または更新するオペレーションがブロックされることを意味します。

    許可アクションは、条件が true と評価された場合にのみ、リソースを作成または更新するオペレーションが許可されることを意味します。条件に明示的にリストされているケースを除き、他のすべてのケースはブロックされます。

  12. [制約を作成] をクリックします。

各フィールドに値を入力すると、このカスタム制約の YAML 構成が右側に表示されます。

gcloud

Google Cloud CLI を使用してカスタム制約を作成するには、カスタム制約の YAML ファイルを作成します。

name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes:
- RESOURCE_NAME
methodTypes:
- METHOD1
- METHOD2
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

以下を置き換えます。

  • ORGANIZATION_ID: 組織 ID(123456789 など)。

  • CONSTRAINT_NAME: 新しいカスタム制約に付ける名前。カスタム制約は custom. で始める必要があります。また、使用できるのは、大文字、小文字、数字のみです(例: custom.disableGkeAutoUpgrade)。このフィールドの最大長は 70 文字です。接頭辞はカウントされません(例: organizations/123456789/customConstraints/custom.)。

  • RESOURCE_NAME: 制限するオブジェクトとフィールドを含む Google Cloud REST リソースの完全修飾名。例: container.googleapis.com/NodePoolリソースタイプごとに最大 20 個のカスタム制約があります。すでに 20 個のカスタム制約があるリソースタイプに対してカスタム制約を作成しようとすると、オペレーションは失敗します。カスタム制約で使用できるサービス リソースの詳細については、カスタム制約でサポートされているサービスをご覧ください。

  • METHOD1,METHOD2: 制約を適用する RESTful メソッドのリスト。CREATECREATEUPDATE のいずれかです。 すべての Google Cloud サービスが両方のメソッドをサポートしているわけではありません。各サービスでサポートされているメソッドを確認するには、サポートされているサービスをご覧ください。

  • CONDITION: サポートされているサービス リソースを参照する CEL 条件(例: "resource.management.autoUpgrade == false")。このフィールドの最大長は 1000 文字です。CEL の使用方法の詳細については、Common Expression Language をご覧ください。

  • ACTION: condition が満たされている場合に実行するアクション。ALLOW または DENY になります。

    拒否アクションは、条件が true と評価された場合に、リソースを作成または更新するオペレーションがブロックされることを意味します。

    許可アクションは、条件が true と評価された場合に、リソースを作成または更新するオペレーションが許可されることを意味します。また、条件に明示的にリストされているケースを除き、他のすべてのケースはブロックされます。

  • DISPLAY_NAME: 制約の名前。わかりやすい名前を入力してください。このフィールドの最大長は 200 文字です。

  • DESCRIPTION: ポリシー違反時にエラー メッセージとして表示される制約の説明。わかりやすい説明を入力してください。このフィールドの最大長は 2,000 文字です。

新しいカスタム制約の YAML ファイルを作成したら、組織内の組織のポリシーで使用できるように設定する必要があります。カスタム制約を設定するには、gcloud org-policies set-custom-constraint コマンドを使用します。

gcloud org-policies set-custom-constraint CONSTRAINT_PATH
CONSTRAINT_PATH は、カスタム制約ファイルのフルパスに置き換えます。たとえば、/home/user/customconstraint.yaml になります。完了すると、カスタム制約が組織のポリシーとして Google Cloud 組織のポリシーのリストに表示されます。カスタム制約が存在することを確認するには、gcloud org-policies list-custom-constraints コマンドを使用します。
gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
ORGANIZATION_ID は組織リソースの ID に置き換えます。 詳細については、組織のポリシーの表示をご覧ください。

カスタム制約を更新する

カスタム制約を更新するには、Google Cloud コンソールで制約を編集するか、新しい YAML ファイルを作成して、gcloud CLI コマンド set-custom-constraint を再度使用します。カスタム制約のバージョニングがないため、これにより既存のカスタム制約が上書きされます。カスタム制約がすでに適用されている場合、更新されたカスタム制約はすぐに有効になります。

Console

  1. Google Cloud コンソールで [組織のポリシー] ページに移動します。

    [組織のポリシー] に移動

  2. ページの上部にあるプロジェクト選択ツールを選択します。

  3. プロジェクト選択ツールから、組織のポリシーを更新するリソースを選択します。

  4. [組織のポリシー] ページのリストから、編集する制約を選択します。その制約の [ポリシーの詳細] ページが表示されます。

  5. [ 制約を編集] をクリックします。

  6. 表示名、説明、適用方法、条件、アクションを変更します。制約を作成した後で、制約 ID またはリソースタイプを変更することはできません。

  7. [Save changes](変更を保存)をクリックします。

gcloud

gcloud CLI を使用して既存のカスタム制約を編集するには、変更する内容を含む新しい YAML ファイルを作成します。

name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes:
- RESOURCE_NAME
methodTypes:
- METHOD1
- METHOD2
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

以下を置き換えます。

  • ORGANIZATION_ID: 組織 ID(123456789 など)。

  • CONSTRAINT_NAME: 新しいカスタム制約に付ける名前。カスタム制約は custom. で始める必要があります。また、使用できるのは、大文字、小文字、数字のみです(例: custom.disableGkeAutoUpgrade)。このフィールドの最大長は 70 文字です。接頭辞はカウントされません(例: organizations/123456789/customConstraints/custom.)。

  • RESOURCE_NAME: 制限するオブジェクトとフィールドを含む Google Cloud REST リソースの完全修飾名。例: container.googleapis.com/NodePoolカスタム制約で使用できるサービス リソースの詳細については、カスタム制約でサポートされているサービスをご覧ください。

  • METHOD1,METHOD2: 制約を適用する RESTful メソッドのリスト。CREATECREATEUPDATE のいずれかです。 すべての Google Cloud サービスが両方のメソッドをサポートしているわけではありません。各サービスでサポートされているメソッドを確認するには、サポートされているサービスをご覧ください。

  • CONDITION: サポートされているサービス リソースを参照する CEL 条件(例: "resource.management.autoUpgrade == false")。このフィールドの最大長は 1000 文字です。CEL の使用方法の詳細については、Common Expression Language をご覧ください。

  • ACTION: condition が満たされている場合に実行するアクション。ALLOW または DENY になります。

  • DISPLAY_NAME: 制約の名前。わかりやすい名前を入力してください。このフィールドの最大長は 200 文字です。

  • DESCRIPTION: ポリシー違反時にエラー メッセージとして表示される制約の説明。わかりやすい説明を入力してください。このフィールドの最大長は 2,000 文字です。

新しいカスタム制約の YAML ファイルを作成したら、組織内の組織のポリシーで使用できるように設定する必要があります。カスタム制約を設定するには、gcloud org-policies set-custom-constraint コマンドを使用します。

gcloud org-policies set-custom-constraint CONSTRAINT_PATH
CONSTRAINT_PATH は、カスタム制約ファイルのフルパスに置き換えます。たとえば、/home/user/customconstraint.yaml になります。完了すると、カスタム制約が組織のポリシーとして Google Cloud 組織のポリシーのリストに表示されます。カスタム制約が存在することを確認するには、gcloud org-policies list-custom-constraints コマンドを使用します。
gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
ORGANIZATION_ID は組織リソースの ID に置き換えます。 詳細については、組織のポリシーの表示をご覧ください。

カスタム制約を削除する

カスタム制約は、Google Cloud コンソールまたは Google Cloud CLI で削除できます。

Console

  1. Google Cloud コンソールで [組織のポリシー] ページに移動します。

    [組織のポリシー] に移動

  2. ページの上部にあるプロジェクト選択ツールを選択します。

  3. プロジェクト選択ツールから、組織のポリシーを削除するリソースを選択します。

  4. [組織のポリシー] ページのリストから、削除する制約を選択します。その制約の [ポリシーの詳細] ページが表示されます。

  5. [削除] をクリックします。

  6. [削除] をクリックして、制約の削除を確定します。

gcloud

カスタム制約を削除するには、org-policies delete-custom-constraint gcloud CLI コマンドを使用します。

gcloud org-policies delete-custom-constraint custom.CONSTRAINT_NAME \
  --organization=ORGANIZATION_ID

以下を置き換えます。

  • ORGANIZATION_ID: 組織 ID(123456789 など)。

  • CONSTRAINT_NAME: カスタム制約の名前。例: custom.disableGkeAutoUpgrade

出力は次のようになります。

Deleted custom constraint [organizations/123456789/customConstraints/custom.disableGkeAutoUpgrade]

カスタム制約を削除しても、その制約を使用して作成されたポリシーは引き続き存在しますが、無視されます。削除したカスタム制約と同じ名前のカスタム制約を作成することはできません。

組織のポリシーの変更をテストして分析する

環境の状態と変更による影響をより深く理解するために、組織のポリシーに対するすべての変更のテストとドライランを行うことをおすすめします。

組織のポリシー用の Policy Simulator は、現在の環境に対する制約と組織のポリシーの影響を理解するのに役立ちます。このツールを使用すると、本番環境に適用する前に、すべてのリソース構成を確認して違反が発生している場所を確認できます。詳しい手順については、Policy Simulator で組織のポリシーへの変更をテストするをご覧ください。

現在の影響を把握したら、ドライラン モードで組織のポリシーを作成して、今後 30 日間のポリシーの影響と潜在的な違反を把握できます。ドライラン モードの組織のポリシーは、ポリシーの違反が監査ログに記録されながら違反アクションは拒否されないタイプの組織のポリシーです。ドライラン モードでカスタムの制約から組織のポリシーを作成するには、Google Cloud コンソールまたは Google Cloud CLI を使用します。詳しい手順については、ドライラン モードで組織のポリシーを作成するをご覧ください。

カスタムの組織のポリシーを適用する

カスタム制約が設定されると、事前定義されたブール値制約と同じように動作します。Google Cloud では、ユーザー リクエストが許可されているかどうかを評価する際に、カスタム制約を最初にチェックします。いずれかのカスタムの組織のポリシーがリクエストを拒否すると、そのリクエストは承認されません。次に、Google Cloud は、そのリソースに適用されている事前定義の組織のポリシーを確認します。

ブール型制約を適用するには、それを参照する組織のポリシーを作成し、それを Google Cloud リソースに適用します。

Console

  1. Google Cloud コンソールで、[組織のポリシー] ページに移動します。

    [組織のポリシー] に移動

  2. プロジェクト選択ツールから、組織のポリシーを設定するプロジェクトを選択します。
  3. [組織のポリシー] ページのリストで制約を選択して、その制約の [ポリシーの詳細] ページを表示します。
  4. このリソースの組織のポリシーを構成するには、[ポリシーを管理] をクリックします。
  5. [ポリシーの編集] ページで、[親のポリシーをオーバーライドする] を選択します。
  6. [ルールの追加] をクリックします。
  7. [適用] セクションで、この組織のポリシーの適用を有効にするかどうかを選択します。
  8. 省略可: タグで組織のポリシーに条件を設定するには、[条件を追加] をクリックします。組織のポリシーに条件付きルールを追加する場合は、少なくとも 1 つは無条件のルールを追加する必要があります。そうしないとポリシーを保存できないのでご注意ください。詳細については、タグ付きの組織のポリシーの設定をご覧ください。
  9. カスタム制約の場合は、[変更内容をテスト] をクリックして、組織のポリシーの効果をシミュレートできます。詳細については、Policy Simulator で組織のポリシーの変更をテストするをご覧ください。
  10. 組織のポリシーを完成させて適用するには、[ポリシーを設定] をクリックします。ポリシーが有効になるまでに最大 15 分かかります。

gcloud

ブール型制約を適用する組織のポリシーを作成するには、制約を参照するポリシー YAML ファイルを作成します。

      name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
      spec:
        rules:
        - enforce: true
    

次のように置き換えます。

  • PROJECT_ID: 制約を適用するプロジェクト。
  • CONSTRAINT_NAME: カスタム制約に定義した名前。例: custom.disableGkeAutoUpgrade

制約を含む組織のポリシーを適用するには、次のコマンドを実行します。

    gcloud org-policies set-policy POLICY_PATH
    

POLICY_PATH は、組織のポリシーの YAML ファイルのパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

制約の例

Google が提供する事前定義の制約と同様のカスタム制約を定義できます。一般的なカスタム制約 YAML ファイルは、次のようになります。

name: organizations/1234567890123/customConstraints/custom.disableGkeAutoUpgrade
resourceTypes:
- container.googleapis.com/NodePool
methodTypes:
- CREATE
- UPDATE
condition: "resource.management.autoUpgrade == false"
actionType: ALLOW
displayName: Disable GKE auto upgrade
description: Only allow GKE NodePool resource to be created or updated if AutoUpgrade is not enabled where this custom constraint is enforced.

Common Expression Language

組織のポリシー サービスは、Common Expression Language(CEL)を使用してカスタム制約の条件を評価します。CEL は、式の評価に共通のセマンティクスを実装するオープンソースの非チューリング完全言語です。

カスタム制約をサポートする各サービスにより、特定のリソースセットとそれらのリソースのフィールドが利用可能になります。使用可能なフィールドは厳密に型指定されており、カスタム制約から直接参照できます。

フィールドのタイプに基づいて、サービス リソース フィールドを参照する CEL 条件を作成できます。組織のポリシー サービスは、CEL データ型、式、マクロのサブセットをサポートしています。以下のセクションでは、使用可能なデータ型と、それらに使用できる共通の式とマクロを示します。

各サービスで使用できる式とマクロの詳細については、カスタム制約がサポートされるサービスをご覧ください。

次の JSON の例は、カスタム制約を使用して参照できる各フィールド タイプを示しています。

{
  integerValue: 1
  stringValue: "A text string"
  booleanValue: true
  nestedValue: {
    nestedStringValue: "Another text string"
  }
  listValue: [foo, bar]
  mapValue["costCenter"] == "123"
}

すべての CEL 式で、条件が true と評価されると、カスタム制約が適用されます。式を and(&&)および or(||)と組み合わせることで、複雑なクエリを作成できます。カスタム制約の YAML または JSON ファイルを作成する場合は、クエリ全体を二重引用符(")で囲みます。

整数

上記の例の integerValue などの整数フィールドでは、条件で比較演算子を使用できます。例:

resource.integerValue == 1
resource.integerValue > 5
resource.integerValue < 10

文字列

上の例の stringValue などの文字列フィールドは、文字列リテラル、正規表現、CEL 式を使用して評価できます。例:

resource.stringValue == "abc"
// stringValue is exactly "abc".

resource.stringValue.matches("dev$")
// stringValue matches a regular expression, which specifies the string ends
// with the word "dev".

resource.stringValue.startsWith("startValue")
// stringValue starts with "startValue".

resource.stringValue.endsWith("endValue")
// stringValue ends with "endValue".

resource.stringValue.contains("fooBar")
// stringValue contains "fooBar".

上記の例の nestedStringValue など、ネストされたフィールドはフルパスで参照する必要があります。例:

resource.nestedValue.nestedStringValue == "foo"
// nestedValue contains the object nestedStringValue, which has a value of "foo".

ブール値

上記の例の booleanValue などのブール値フィールドには、true または false のいずれかのブール値が含まれています。

リスト

上記の例の listValue などのリストフィールドは、リストのサイズ、リストの内容、リスト内の特定の要素が存在するかどうかで評価できます。

例:

resource.listValue.size() >= 1 && resource.listValue[0] == "bar"
// listValue has size greater than or equal to one, and the first element is "bar".

resource.listValue.exists(value, value == "foo")
// listValue has at least one element that is exactly "foo".

resource.listValue.all(value, value.contains("foo"))
// listValue is a list of values that are all exactly "foo".

地図

上記の例の mapValue などのマップ フィールドは、特定の要素の存在と値に基づいて評価できる Key-Value ペアです。

例:

has(resource.mapValue.foo) && resource.mapValue.foo == "bar"
// mapValue contains the key "foo", and that key has the value "bar".

CEL エラーのトラブルシューティング

無効な式や型の不一致を使用して作成された条件では、カスタム制約を設定しようとするとエラーを返します。たとえば、次の無効なカスタム制約があるとします。この制約は、文字列を整数と比較します。

name: organizations/1234567890123/customConstraints/custom.badConfig
resourceTypes:
- dataproc.googleapis.com/Cluster
methodTypes:
- CREATE
- UPDATE
condition: "resource.config.masterConfig.numInstances == 'mismatch'"
actionType: ALLOW
displayName: Number of instances is a string
description: Demonstrate that type mismatches cause an error.

Google Cloud CLI を使用してこの制約を設定しようとすると、エラーが発生します。

ERROR: (gcloud.org-policies.set-custom-constraint) INVALID_ARGUMENT: Custom constraint condition [resource.config.masterConfig.numInstances == "mismatch"] is invalid. Error: ERROR: <input>:1:15: found no matching overload for '_==_' applied to '(int, string)' (candidates: (%A0, %A0))
 | resource.config.masterConfig.numInstances == "mismatch"
 | ..........................................^.

Google Cloud コンソールでは、無効な CEL 構文エラーは [ エラー] アイコンが表示されます。このアイコンをハイライト表示すると、構文エラーの詳細を含むツールチップが表示されます。

組織のポリシー サービスは、作成した条件をコンパイルして検証し、条件が構文的に正しくない場合はエラーを返します。ただし、コンパイルする特定の条件がありますが、Google Cloud が制約を適用しようとするとエラーが発生します。たとえば、存在しないリスト インデックスまたはマップキーにアクセスしようとする条件で制約を設定すると、制約は失敗して適用時にエラーを返し、リソースの作成をブロックします

リスト要素またはマップ要素に依存する条件を作成する場合は、すべてのケースで条件が有効であることを確認するチェックで条件を開始することをおすすめします。たとえば、特定のリスト要素を参照する前に list.size() を確認するか、マップ要素を参照する前に has() を使用します。

サポート対象のサービス

各サービスは、サービス リソースに組織のポリシーを適用するために使用できる一連のカスタム制約フィールドを定義します。カスタム制約をサポートするサービスの一覧については、カスタム制約でサポートされているサービスをご覧ください。

組織のポリシーのスキャナの設定の詳細については、組織のポリシーの脆弱性の検出をご覧ください。

次のステップ