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

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

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

準備

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

    gcloud config set project PROJECT_ID

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

  • Policy Simulator and Resource Manager API を有効にします。

    API を有効にする

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

必要なロール

シミュレーションの実行とアクセスに必要な権限を取得するには、組織に対する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

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

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

カスタム制約、カスタム制約を適用する組織のポリシー、またはその両方への変更をテストできます。

コンソール

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

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

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

  3. プロジェクト選択ツールから、組織のポリシーへの変更をテストするリソースを選択します。カスタム制約への変更をテストするには、組織リソースを選択する必要があります。

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

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

    たとえば、Binary Authorization が有効になっていない Google Kubernetes Engine クラスタ リソースの作成を制限するカスタム制約を定義するには、次のようにします。

    1. [リソースの種類] ボックスで [container.googleapis.com/Cluster] を選択します。

    2. [適用方法] で [作成時に適用する] を選択します。

    3. [条件を編集] をクリックします。

    4. [条件を追加] パネルに「resource.binaryAuthorization.enabled == true」と入力します。

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

    6. [アクション] で [許可] を選択します。

    詳しくは、カスタムロールの作成と管理をご覧ください。

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

  7. 新しい制約、または組織のポリシーによって適用されていない制約の場合は、組織のポリシーを定義する必要があります。

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

    2. [カスタマイズ] をクリックします。

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

    4. [適用] で、[オン] を選択し、[完了] をクリックします。

    5. [続行] をクリックします。

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

gcloud

  1. カスタム制約をテストするには、テストするカスタム制約を定義する JSON ファイルまたは YAML ファイルを作成します。

    たとえば、Binary Authorization が有効になっていない Google Kubernetes Engine クラスタ リソースの作成を制限するカスタム制約は次のようになります。

    name: "organizations/ORGANIZATION_ID/customConstraints/custom.EnforceGKEBinaryAuthz"
    resource_types: "container.googleapis.com/Cluster"
    method_types: CREATE
    condition: "resource.binaryAuthorization.enabled == true"
    action_type: ALLOW
    

    ORGANIZATION_ID は、組織 ID(1234567890123 など)に置き換えます。

    カスタム制約の作成方法については、カスタム制約の作成と管理をご覧ください。

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

    たとえば、次の組織のポリシーでは、タグ env=dev が適用されているリソースを除き、Binary Authorization が有効になっていない Google Kubernetes Engine クラスタ リソースの作成が制限されます。

    name: "organizations/ORGANIZATION_ID/policies/custom.EnforceGKEBinaryAuthz"
    spec:
        rules:
       - condition:
           expression: resource.matchTag('env', 'dev')
         enforce: false
       - enforce: true
    

    ORGANIZATION_ID は、組織 ID に置き換えます(1234567890123 など)。

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

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

    たとえば、Binary Authorization が有効になっていない Google Kubernetes Engine クラスタ リソースの作成を制限する組織のポリシーは次のようになります。

    name: "organizations/ORGANIZATION_ID/policies/custom.EnforceGKEBinaryAuthz"
    spec:
        rules:
        - enforce: true
    

    ORGANIZATION_ID は、組織 ID(1234567890123 など)に置き換えます。

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

    たとえば、次の組織のポリシーは、既存の custom.EnforceGKEBinaryAuthz カスタム制約の削除をシミュレートします。

    name: "organizations/ORGANIZATION_ID/policies/custom.EnforceGKEBinaryAuthz"
    spec:
          inheritFromParent: true
    
  5. 次のコマンドを実行して、カスタム制約、組織のポリシー、またはその両方への変更をシミュレートします。

    gcloud beta 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-projectorgpolicy-test-cluster とプロジェクト autopilot-cluster-1 の 2 つのクラスタ リソースがポリシー違反になります。 orgpolicy-test-0

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

Policy Simulator の結果

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

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

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

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

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

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

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

カスタム制約、組織のポリシー、またはその両方をテストしたら、カスタム制約を設定して組織のポリシーを適用できます。Policy Simulator のすべての結果は、生成方法に関係なく Google Cloud コンソールで確認できます。シミュレーション レポートに複数の組織のポリシーへの変更が含まれている場合は、シミュレーションの結果を介して組織のポリシーを直接適用できます。複数の組織のポリシーでテストの変更を適用するには、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 は、出力ファイルの名前に置き換えます。

次のステップ