Policy Simulator で組織のポリシーの変更をテストする

組織のポリシー用の Policy Simulator を使用すると、本番環境に適用する前に、新しいカスタム制約またはマネージド制約を適用する組織のポリシーの影響をプレビューできます。Policy Simulator は、提案されたポリシーに違反する前に適用されるリソースのリストを提供します。これにより、これらのリソースを再構成し、例外をリクエストし、組織ポリシーの範囲を中断することなく、デベロッパーと連携するなどして、環境をダウンさせます。

このページでは、Policy Simulator を使用して組織のポリシーに対する変更をテストする方法について説明します。また、シミュレーションの結果を解釈する方法と、テスト済みの組織のポリシーを適用する方法（そのように選択した場合）についても説明します。

準備

• Google Cloud CLI を使用している場合は、API 呼び出しを行うプロジェクトを設定します。

  gcloud config set project PROJECT_ID

  PROJECT_ID は、プロジェクトの名前または ID に置き換えます。

• Enable the Policy Simulator and Resource Manager APIs.

  Roles required to enable APIs

  To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

  Enable the APIs

• 省略可: 組織ポリシー サービスの概要を確認します。

必要なロール

シミュレーションの実行とアクセスに必要な権限を取得するには、組織に対する OrgPolicy Simulator 管理者 （roles/policysimulator.orgPolicyAdmin）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

この事前定義ロールには、シミュレーションの実行とアクセスに必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

シミュレーションを実行してアクセスするには、次の権限が必要です。

• orgpolicy.constraints.list
• orgpolicy.customConstraints.get
• orgpolicy.policies.list
• cloudasset.assets.searchAllResources
• cloudasset.assets.listResource
• cloudasset.assets.listOrgPolicy
• policysimulator.orgPolicyViolationsPreviews.list
• policysimulator.orgPolicyViolationsPreviews.get
• policysimulator.orgPolicyViolationsPreviews.create
• policysimulator.orgPolicyViolations.list

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

ポリシーの変更をテストする

カスタム制約またはマネージド制約を適用する組織のポリシー、またはその両方に対する変更を一度にテストできます。

注: Policy Simulator は、以前のマネージド制約への変更をテストできません。

カスタム制約に対する変更をテストする

コンソール

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

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

2. 組織選択ツールから自分の組織を選択します。

3. 次のいずれかを行います。

   • 新しいカスタム制約をテストするには、 [カスタム制約] をクリックします。

   • 既存のカスタム制約に変更を加える場合は、[組織のポリシー] ページでリストから選択し、 [制約を編集] をクリックします。

4. テストするカスタム制約を作成または更新します。

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

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

      カスタム制約を作成した後で、制約 ID を変更することはできません。

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

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

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

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

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

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

   9. [アクション] セクションで、記述した条件が満たされた場合に、評価されたメソッドを許可するか拒否するかを選択します。

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

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

5. [制約をテスト] をクリックします。

6. 新しい制約の場合は、[組織のポリシーを構成] ペインが表示されます。カスタム制約を適用する組織のポリシーを定義する手順は次のとおりです。

   1. [範囲を選択] ボックスで、このカスタム制約をテストするリソースを選択します。

   2. [親のポリシーをオーバーライドする] をクリックします。

   3. [ルールの追加] をクリックします。

   4. [適用] セクションで、[オン] を選択します。

   5. タグで組織のポリシーに条件を設定するには、[条件を追加] をクリックします。組織のポリシーに条件付きルールを追加する場合は、少なくとも 1 つは無条件のルールを追加する必要があります。そうしないとポリシーを保存できないのでご注意ください。詳細については、タグを使用した組織のポリシーの設定をご覧ください。

   6. [完了]、[続行] の順にクリックします。

[シミュレーションの履歴] ページが表示され、過去 14 日間に実行したシミュレーションのリストが表示されます。詳細については、このページの Policy Simulator の結果についてをご覧ください。

gcloud

1. 新しいカスタム制約または更新されたカスタム制約の適用をテストするには、テストするカスタム制約を定義する JSON ファイルまたは YAML ファイルを作成します。

   既存のカスタム制約の変更をテストする場合は、organizations.customConstraints.get gcloud CLI コマンドを使用して、カスタム制約の現在の JSON または YAML 表現を取得し、そのファイルを編集できます。

   カスタム制約を定義する 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 個のカスタム制約を設定できます。すでに最大数のカスタム制約があるリソースに対してカスタム制約を作成しようとすると、オペレーションは失敗します。カスタム制約で使用できるサービス リソースの詳細については、カスタム制約でサポートされているサービスをご覧ください。

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

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

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

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

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

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

   • DESCRIPTION: ポリシー違反時にエラー メッセージとして表示される制約の説明。わかりやすい説明を入力してください。このフィールドの最大長は 2, 000 です。カスタム制約の作成方法の詳細については、カスタム制約の作成と管理をご覧ください。

2. カスタム制約を適用する組織のポリシーを作成または変更します。

   • 新しいカスタム制約または更新されたカスタム制約の適用をテストするには、テストする組織のポリシーを定義する JSON ファイルまたは YAML ファイルを作成します。

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       rules:
       - enforce: true
     

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

     • ORGANIZATION_ID は、組織 ID（1234567890123 など）に置き換えます。

     • CONSTRAINT_NAME は、テストするカスタム制約の名前に置き換えます。例: custom.EnforceGKEBinaryAuthz

   • 特定のタグの存在に基づいて条件付きでカスタム制約を適用するテストを行うには、組織のポリシーを定義する JSON ファイルまたは YAML ファイルを作成します。

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       rules:
       - condition:
           expression: CONDITION
         enforce: false
       - enforce: true
     

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

     • ORGANIZATION_ID は、組織 ID（1234567890123 など）に置き換えます。

     • CONSTRAINT_NAME は、テストするカスタム制約の名前に置き換えます。例: custom.EnforceGKEBinaryAuthz

     • サポートされているサービス リソースを参照する CEL 条件を含む CONDITION（例: "resource.matchTag('env', 'dev')"）。

     条件付き組織のポリシーの詳細については、タグを使用した組織のポリシーの設定をご覧ください。

   • カスタム制約を適用する組織のポリシーの削除をテストするには、親リソースからポリシーを継承する以外のルールが設定されていない組織のポリシーを定義する JSON ファイルまたは YAML ファイルを作成します。

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       inheritFromParent: true
     

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

     • ORGANIZATION_ID は、組織 ID（1234567890123 など）に置き換えます。

     • CONSTRAINT_NAME は、テストするカスタム制約の名前に置き換えます。例: custom.EnforceGKEBinaryAuthz

3. カスタム制約、組織のポリシー、またはその両方に対する変更をシミュレートするには、policy-intelligence simulate orgpolicy コマンドを実行します。

   gcloud policy-intelligence simulate orgpolicy \
     --organization=ORGANIZATION_ID \
     --custom-constraints=CONSTRAINT_PATH \
     --policies=POLICY_PATH
   

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

   • ORGANIZATION_ID: 組織 ID（1234567890123 など）。 複数の組織にわたる変更のシミュレーションはサポートされていません。

   • CONSTRAINT_PATH: 作成または更新したカスタム制約のフルパス。例: tmp/constraint.yaml。--policies フラグを設定すると、--custom-constraints フラグを設定する必要はありません。

   • POLICY_PATH: 作成または更新した組織のポリシーの完全パス。次に例を示します。tmp/policy.yaml --custom-constraintsフラグを設定すると、 --policies　フラグを設定する必要はありません。

数分後、カスタム制約、組織のポリシー、またはその両方に対する変更に違反するリソースリストが出力されます。

結果は、 Google Cloud コンソールの [シミュレーションの履歴] ページでも確認できます。結果の読み方については、このページの Policy Simulator の結果をご覧ください。

組織のポリシーのシミュレーションのレスポンスの例を次に示します。 このシミュレーションでは、Binary Authorization が有効になっていない Google Kubernetes Engine クラスタ リソースの作成を制限するカスタム制約が使用されます。この場合、変更案が適用されると、プロジェクト simulator-test-project の orgpolicy-test-cluster とプロジェクト orgpolicy-test-0 のautopilot-cluster-1 の 2 つのクラスタ リソースがポリシー違反になります。

Waiting for operation [organizations/012345678901/locations/global/orgPolic
yViolationsPreviews/85be9a2d-8c49-470d-a65a-d0cb9ffa8f83/operations/1883a83
c-c448-42e5-a7c5-10a850928f06] to complete...done.
---
customConstraint:
  actionType: ALLOW
  condition: resource.binaryAuthorization.enabled == true
  methodTypes:
  - CREATE
  name: organizations/012345678901/customConstraints/custom.EnforceGKEBinaryAuthz
  resourceTypes:
  - container.googleapis.com/Cluster
name: organizations/012345678901/locations/global/orgPolicyViolationsPreviews/3dd47fd3-6df1-4156-8f10-413a3fc0ed83/orgPolicyViolations/b9fd23a5-7163-46de-9fec-7b9aa6af1113
resource:
  ancestors:
  - organizations/012345678901
  - projects/456789012345
  assetType: container.googleapis.com/Cluster
  resource: //container.googleapis.com/projects/simulator-test-project/locations/us-central1/clusters/orgpolicy-test-cluster
---
customConstraint:
  actionType: ALLOW
  condition: resource.binaryAuthorization.enabled == true
  methodTypes:
  - CREATE
  name: organizations/012345678901/customConstraints/custom.EnforceGKEBinaryAuthz
  resourceTypes:
  - container.googleapis.com/Cluster
name: organizations/012345678901/locations/global/orgPolicyViolationsPreviews/3dd47fd3-6df1-4156-8f10-413a3fc0ed83/orgPolicyViolations/e73896e6-7613-4a8d-8436-5df7a6455121
resource:
  ancestors:
  - organizations/012345678901
  - folders/789012345678
  - projects/456789012345
  assetType: container.googleapis.com/Cluster
  resource: //container.googleapis.com/projects/orgpolicy-test-0/locations/us-central1/clusters/autopilot-cluster-1

マネージド制約の変更をテストする

コンソール

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

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

2. [プロジェクトを選択] をクリックし、組織のポリシーを編集する対象の組織、フォルダ、またはプロジェクト リソースを選択します。

3. リストから、組織のポリシーを更新するマネージド制約を選択します。[ポリシーの詳細] ページで、この組織のポリシーのソース、このリソースに対する有効なポリシー評価、管理対象の制約の詳細などを確認できます。

4. このリソースの組織のポリシーを更新するには、[ポリシーを管理] をクリックします。

5. [ポリシーの編集] ページで、[親のポリシーをオーバーライドする] を選択します。

6. [ルールの追加] をクリックします。

7. [適用] セクションで、この組織のポリシーの適用を有効にするかどうかを選択します。

8. タグで組織のポリシーに条件を設定するには、[条件を追加] をクリックします。組織のポリシーに条件付きルールを追加する場合は、少なくとも 1 つは無条件のルールを追加する必要があります。そうしないとポリシーを保存できないのでご注意ください。詳細については、タグを使用した組織のポリシーの設定をご覧ください。

9. [変更をテスト] をクリックします。

[シミュレーションの履歴] ページが表示され、過去 14 日間に実行したシミュレーションのリストが表示されます。詳細については、このページの Policy Simulator の結果についてをご覧ください。

gcloud

1. マネージド制約を適用する組織のポリシーを作成または変更します。

   • マネージド制約を適用する組織のポリシーの作成または更新をテストするには、組織のポリシーを定義する JSON ファイルまたは YAML ファイルを作成します。

     name: RESOURCE_TYPE/RESOURCE_ID/policies/CONSTRAINT_NAME
     spec:
       rules:
       - enforce: ENFORCEMENT_STATE
     

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

     • RESOURCE_TYPE は organizations、folders、または projects に置き換えます。

     • RESOURCE_ID は、RESOURCE_TYPE で指定されたリソースのタイプに応じた、組織 ID、フォルダ ID、プロジェクト ID またはプロジェクト番号に置き換えます。

     • CONSTRAINT_NAME は、テストするマネージド制約の名前に置き換えます。例: iam.managed.disableServiceAccountKeyCreation

     • ENFORCEMENT_STATE と true を使用して、設定時にこの組織のポリシーを適用します。または、false を使用して、設定時にこの組織のポリシーを無効にします。

     タグで組織のポリシーに条件を設定するには、rules に condition ブロックを追加します。組織のポリシーに条件付きルールを追加する場合は、少なくとも 1 つは無条件のルールを追加する必要があります。そうしないとポリシーを保存できないのでご注意ください。詳細については、タグを使用した組織のポリシーの設定をご覧ください。

     注: Policy Simulator では、同じ組織で定義されたタグのみがサポートされます。別の組織でタグが定義されている場合、Policy Simulator はエラーを返し、シミュレーションを完了しません。

   • マネージド制約を適用する組織のポリシーの削除をテストするには、親リソースからポリシーを継承する以外のルールが設定されていない組織のポリシーを定義する JSON ファイルまたは YAML ファイルを作成します。

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       inheritFromParent: true
     

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

   • ORGANIZATION_ID は、組織 ID に置き換えます。

   • CONSTRAINT_NAME は、削除するマネージド制約の名前に置き換えます。例: iam.managed.disableServiceAccountKeyCreation

2. policy-intelligence simulate orgpolicy コマンドを実行します。

   gcloud policy-intelligence simulate orgpolicy \
     --organization=ORGANIZATION_ID \
     --policies=POLICY_PATH
   

   以下を置き換えます。

   • ORGANIZATION_ID は、組織 ID（1234567890123 など）に置き換えます。複数の組織にわたる変更のシミュレーションはサポートされていません。

   • POLICY_PATH は、組織のポリシーの YAML ファイルのパスに置き換えます。

   数分後、カスタム制約、組織のポリシー、またはその両方に対する変更に違反するリソースリストが出力されます。

   結果は、 Google Cloud コンソールの [シミュレーションの履歴] ページでも確認できます。結果の読み方については、このページの Policy Simulator の結果をご覧ください。

Policy Simulator の結果

Policy Simulator は、カスタム制約または組織のポリシーでの変更の結果を、シミュレートされたポリシーの違反のリストとしてレポートします。Google Cloud コンソールには、過去 14 日間に生成されたシミュレーションの結果が保存されます。

シミュレーション結果を表示するには、[シミュレーションの履歴] ページに移動します。

[シミュレーションの履歴] に移動する

シミュレーションを選択して詳細を表示します。[シミュレーション レポート] ページには、違反のプレビューが表示されます。ここには、新しいカスタム制約または組織のポリシーによって引き起こされた違反の合計数と、シミュレーションのスコープでチェックされたリソースの数とシミュレーションが完了した時刻が表示されます。

カスタム制約をシミュレートした場合は、[制約の詳細] をクリックして、シミュレートされた特定の構成を確認できます。組織のポリシーをシミュレートした場合、[ポリシーの詳細] タブには、シミュレートされた構成が表示されます。

すべての違反がリソースのテーブルに表示されます。新しいカスタム制約または組織のポリシーに違反している各リソースが、Cloud Asset Inventory のリソース エントリへのリンクとともに一覧表示されます。プロジェクト、フォルダ、組織のリソースが、新しいカスタム制約または組織のポリシーに違反する階層内のリソースの合計とともに表示されます。

テスト済みのポリシー変更を適用する

カスタム制約、組織のポリシー、またはその両方をテストしたら、カスタム制約を設定して組織のポリシーを適用できます。Policy Simulator のすべての結果は、生成方法に関係なく Google Cloud コンソールで確認できます。シミュレーション レポートに含まれる組織のポリシーへの変更が 1 つのみの場合は、シミュレーション結果から直接組織のポリシーを適用できます。複数の組織のポリシーのテスト変更を適用するには、Google Cloud CLI を使用します。

コンソール

1. カスタム制約に Policy Simulator の結果を適用するには、[シミュレーションの履歴] ページに移動します。

   [シミュレーションの履歴] に移動する

2. 適用するカスタム制約または組織のポリシーのシミュレーション レポートを選択します。

3. このシミュレーション レポートにカスタム制約が含まれている場合は、[制約を保存] をクリックします。

4. このシミュレーション レポートに複数の組織のポリシーへの変更が含まれている場合は、その組織のポリシーをドライラン ポリシーとして適用し、[ドライラン ポリシーを設定] をクリックして、リスクを発生させることなく本番環境の動作をモニタリングできます。新しい組織のポリシーのページの [ポリシーの詳細] ページが表示されます。

   をクリックし、[ポリシーを設定] をクリックすると、組織のポリシーをすぐに適用できます。

gcloud

1. カスタム制約を適用するには、組織で組織のポリシーで使用できるように設定する必要があります。カスタム制約を設定するには、gcloud org-policies set-custom-constraint コマンドを使用します。

   gcloud org-policies set-custom-constraint CONSTRAINT_PATH
   

   CONSTRAINT_PATH は、カスタム制約ファイルのフルパスに置き換えます。例: /home/user/customconstraint.yaml

   設定が完了すると、カスタム制約が Google Cloud 組織のポリシーのリストに表示されます。

2. 組織のポリシーを設定するには、gcloud org-policies set-policy コマンドを使用します。

   gcloud org-policies set-policy POLICY_PATH
   

   POLICY_PATH は、組織のポリシーの YAML ファイルのパスに置き換えます。

   ポリシーが有効になるまでに最大 15 分かかります。

シミュレーション結果を保存する

コンソール

Google Cloud コンソールを使用している場合は、Policy Simulator の結果を CSV ファイルとして保存できます。

1. Policy Simulator の結果を保存するには、[シミュレーションの履歴] ページに移動します。

   [シミュレーションの履歴] に移動する

2. 保存するシミュレーション レポートを選択します。

3. [結果全体をエクスポート] をクリックします。

gcloud

gcloud CLI を使用している場合は、Policy Simulator の結果を JSON ファイルまたは YAML ファイルとして保存できます。

デフォルトでは、Google Cloud CLI のテスト結果は YAML 形式で出力されます。テスト結果を YAML ファイルとして保存するには、シミュレーションの実行時に simulate orgpolicy コマンドの出力をリダイレクトします。

> FILENAME

FILENAME は、出力ファイルの名前に置き換えます。

テスト結果を JSON ファイルとして保存するには、シミュレーションを実行するときに次のフラグを simulate orgpolicy コマンドに追加します。

--format=json > FILENAME

FILENAME は、出力ファイルの名前に置き換えます。

次のステップ

• 制約の詳細を確認する。
• ポリシーのカスタマイズに使用できるその他のオプションを確認する。
• タグに基づいて組織のポリシーを設定する方法を確認する。