Änderungen an Organisationsrichtlinien mit dem Policy Simulator testen

Console

1. Rufen Sie in der Google Cloud Console die Seite Organisationsrichtlinien auf.

   Zu den Organisationsrichtlinien

2. Wählen Sie in der Organisationsauswahl Ihre Organisationsressource aus.

3. Führen Sie einen der folgenden Schritte aus:

   • Wenn Sie eine neue benutzerdefinierte Einschränkung testen möchten, klicken Sie auf add Benutzerdefinierte Einschränkung.

   • Wenn Sie Änderungen an einer vorhandenen benutzerdefinierten Einschränkung vornehmen möchten, wählen Sie sie auf der Seite Organisationsrichtlinien aus der Liste aus und klicken Sie dann auf edit Einschränkung bearbeiten.

4. Erstellen oder aktualisieren Sie die benutzerdefinierte Einschränkung, die Sie testen möchten.

   1. Geben Sie im Feld Anzeigename einen nutzerfreundlichen Namen für die Einschränkung ein. Dieses Feld hat eine maximale Länge von 200 Zeichen. Verwenden Sie keine personenidentifizierbaren Informationen oder vertraulichen Daten in Anzeigenamen, da diese in Fehlermeldungen angezeigt werden können.

   2. Geben Sie im Feld Einschränkungs-ID den gewünschten Namen für die neue benutzerdefinierte Einschränkung ein. Eine benutzerdefinierte Einschränkung muss mit custom. beginnen und darf nur Großbuchstaben, Kleinbuchstaben oder Ziffern enthalten, z. B. custom.disableGkeAutoUpgrade. Die maximale Länge dieses Feldes beträgt 70 Zeichen, das Präfix wird nicht gezählt (z. B. organizations/123456789/customConstraints/custom.). Beziehen Sie weder personenidentifizierbare Informationen noch sensible Daten in die ID der Einschränkung ein, da sie in Fehlermeldungen preisgegeben werden könnten.

      Die Constraint-ID kann nach dem Erstellen einer benutzerdefinierten Einschränkung nicht mehr geändert werden.

   3. Geben Sie im Feld Beschreibung eine nutzerfreundliche Beschreibung der Einschränkung ein, die bei einer Verletzung der Richtlinie als Fehlermeldung angezeigt wird. Dieses Feld hat eine maximale Länge von 2000 Zeichen. Beziehen Sie weder personenidentifizierbare Informationen noch sensible Daten in die Beschreibung ein, da sie in Fehlermeldungen preisgegeben werden könnten.

   4. Wählen Sie im Feld Ressourcentyp den Namen der REST-Ressource von Google Cloudaus, die das Objekt und das Feld enthält, das Sie einschränken möchten, z. B. container.googleapis.com/NodePool. Für die meisten Ressourcentypen können maximal 20 benutzerdefinierte Einschränkungen pro Ressource festgelegt werden. Wenn Sie versuchen, eine benutzerdefinierte Einschränkung für eine Ressource zu erstellen, die bereits die maximale Anzahl benutzerdefinierter Einschränkungen hat, schlägt der Vorgang fehl.

   5. Wählen Sie im Bereich Methode erzwingen aus, ob die Einschränkung für eine REST-Methode CREATE oder sowohl für die Methoden CREATE als auch UPDATE erzwungen werden soll. Nicht alle Google Cloud Dienste unterstützen beide Methoden. Die unterstützten Methoden für die einzelnen Dienste finden Sie unter Unterstützte Dienste.

   6. Klicken Sie zum Definieren einer Bedingung auf edit Bedingung bearbeiten.

   7. Erstellen Sie im Bereich Bedingung hinzufügen eine CEL-Bedingung, die auf eine unterstützte Dienstressource verweist, z. B. resource.management.autoUpgrade == false. Dieses Feld hat eine maximale Länge von 1.000 Zeichen. Weitere Informationen zur Verwendung von CEL finden Sie unter Common Expression Language. Weitere Informationen zu den Dienstressourcen, die Sie in Ihren benutzerdefinierten Einschränkungen verwenden können, finden Sie unter Von benutzerdefinierten Einschränkungen unterstützte Dienste.

   8. Klicken Sie auf Speichern.

   9. Wählen Sie im Abschnitt Aktion aus, ob die ausgewertete Methode zugelassen oder abgelehnt werden soll, wenn die von Ihnen formulierte Bedingung erfüllt ist.

      Die Aktion „Verweigern“ bedeutet, dass der Vorgang zum Erstellen oder Aktualisieren der Ressource blockiert wird, wenn die Bedingung als „true“ ausgewertet wird.

      Die Aktion „Zulassen“ bedeutet, dass der Vorgang zum Erstellen oder Aktualisieren der Ressource nur zulässig ist, wenn die Bedingung als „true“ ausgewertet wird. Alle anderen Fälle mit Ausnahme der im Bedingungsterm ausdrücklich aufgeführten werden blockiert.

5. Klicken Sie auf Einschränkung testen.

6. Wenn es sich um eine neue Einschränkung handelt, wird der Bereich Organisationsrichtlinie konfigurieren angezeigt. So definieren Sie eine Organisationsrichtlinie, die die benutzerdefinierte Einschränkung erzwingt:

   1. Wählen Sie im Feld Bereich auswählen die Ressource aus, für die Sie die benutzerdefinierte Einschränkung testen möchten.

   2. Klicken Sie auf Richtlinie der übergeordneten Ressource überschreiben.

   3. Klicken Sie auf Regel hinzufügen.

   4. Wählen Sie im Abschnitt Erzwingung die Option Ein aus.

   5. Klicken Sie optional auf Bedingung hinzufügen, um die Organisationsrichtlinie von einem Tag abhängig zu machen. Wenn Sie einer Organisationsrichtlinie eine bedingte Regel hinzufügen, müssen Sie mindestens eine bedingungslose Regel hinzufügen. Andernfalls kann die Richtlinie nicht gespeichert werden. Weitere Informationen finden Sie unter Organisationsrichtlinie mit Tags festlegen.

   6. Klicken Sie auf Fertig und dann auf Weiter.

Die Seite Simulationsverlauf wird angezeigt. Sie enthält eine Liste der Simulationen, die Sie in den letzten 14 Tagen ausgeführt haben. Weitere Informationen finden Sie auf dieser Seite unter Ergebnisse des Richtliniensimulators.

gcloud

1. Wenn Sie die Erzwingung einer neuen oder aktualisierten benutzerdefinierten Einschränkung testen möchten, erstellen Sie eine JSON- oder YAML-Datei, in der die benutzerdefinierte Einschränkung definiert ist, die Sie testen möchten.

   Wenn Sie Änderungen an einer vorhandenen benutzerdefinierten Einschränkung testen möchten, können Sie mit dem gcloud CLI-Befehl organizations.customConstraints.get die aktuelle JSON- oder YAML-Darstellung der benutzerdefinierten Einschränkung abrufen und dann Änderungen an dieser Datei vornehmen.

   Eine YAML-Datei, die eine benutzerdefinierte Einschränkung definiert, sieht in etwa so aus:

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

   Ersetzen Sie Folgendes:

   • ORGANIZATION_ID: Ihre Organisations-ID, z. B. 123456789.

   • CONSTRAINT_NAME: Name, den Sie für Ihre neue benutzerdefinierte Einschränkung verwenden möchten. Eine benutzerdefinierte Einschränkung muss mit custom. beginnen und darf nur Großbuchstaben, Kleinbuchstaben oder Ziffern enthalten, z. B. custom.disableGkeAutoUpgrade. Die maximale Länge dieses Feldes beträgt 70 Zeichen, das Präfix wird nicht gezählt (z. B. organizations/123456789/customConstraints/custom.).

   • RESOURCE_NAME: der vollständig qualifizierte Name derGoogle Cloud REST-Ressource, die das Objekt und das Feld enthält, das Sie einschränken möchten. Beispiel: container.googleapis.com/NodePool Für die meisten Ressourcentypen sind maximal 20 benutzerdefinierte Einschränkungen pro Ressource möglich. Wenn Sie versuchen, eine benutzerdefinierte Einschränkung für eine Ressource zu erstellen, die bereits die maximale Anzahl benutzerdefinierter Einschränkungen hat, schlägt der Vorgang fehl. Weitere Informationen zu den Dienstressourcen, die Sie in Ihren benutzerdefinierten Einschränkungen verwenden können, finden Sie unter Von benutzerdefinierten Einschränkungen unterstützte Dienste.

   • METHOD1,METHOD2: Liste der RESTful-Methoden, für die die Einschränkung erzwungen werden soll. Kann CREATE oder CREATE und UPDATE sein. Nicht alle Google Cloud Dienste unterstützen beide Methoden. Die unterstützten Methoden für die einzelnen Dienste finden Sie unter Unterstützte Dienste.

   • CONDITION: eine CEL-Bedingung, die auf eine unterstützte Dienstressource verweist, z. B. "resource.management.autoUpgrade == false". Dieses Feld hat eine maximale Länge von 1.000 Zeichen. Weitere Informationen zur Verwendung von CEL finden Sie unter Common Expression Language.

   • ACTION: Aktion, die ausgeführt werden soll, wenn condition erfüllt ist. Dies kann entweder ALLOW oder DENY sein.

     • Die Aktion „Verweigern“ bedeutet, dass der Vorgang zum Erstellen oder Aktualisieren der Ressource blockiert wird, wenn die Bedingung als wahr ausgewertet wird.

     • Die Aktion „Zulassen“ bedeutet, dass der Vorgang zum Erstellen oder Aktualisieren der Ressource zulässig ist, wenn die Bedingung als „wahr“ ausgewertet wird. Das bedeutet auch, dass jeder andere Fall als der in der Bedingung explizit aufgeführte blockiert wird.

   • DISPLAY_NAME: Ein nutzerfreundlicher Name für die Einschränkung. Dieses Feld hat eine maximale Länge von 200 Zeichen.

   • DESCRIPTION: Eine nutzerfreundliche Beschreibung der Einschränkung, die als Fehlermeldung angezeigt werden soll, wenn die Richtlinie verletzt wird Dieses Feld hat eine maximale Länge von 2.000 Zeichen. Weitere Informationen zum Erstellen benutzerdefinierter Einschränkungen finden Sie unter Benutzerdefinierte Einschränkungen erstellen und verwalten.

2. Erstellen oder ändern Sie eine Organisationsrichtlinie, die die benutzerdefinierte Einschränkung erzwingt.

   • Wenn Sie das Erzwingen einer neuen oder aktualisierten benutzerdefinierten Einschränkung testen möchten, erstellen Sie eine JSON- oder YAML-Datei, in der die Organisationsrichtlinie definiert ist, die Sie testen möchten:

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

     Ersetzen Sie Folgendes:

     • ORGANIZATION_ID durch Ihre Organisations-ID, z. B. 1234567890123.

     • Ersetzen Sie CONSTRAINT_NAME durch den Namen der benutzerdefinierten Einschränkung, die Sie testen möchten. Beispiel: custom.EnforceGKEBinaryAuthz

   • Wenn Sie das Erzwingen einer benutzerdefinierten Einschränkung basierend auf dem Vorhandensein eines bestimmten Tags testen möchten, erstellen Sie eine JSON- oder YAML-Datei, die die Organisationsrichtlinie definiert:

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

     Ersetzen Sie Folgendes:

     • ORGANIZATION_ID durch Ihre Organisations-ID, z. B. 1234567890123.

     • Ersetzen Sie CONSTRAINT_NAME durch den Namen der benutzerdefinierten Einschränkung, die Sie testen möchten. Beispiel: custom.EnforceGKEBinaryAuthz

     • CONDITION mit einer CEL-Bedingung, die auf eine unterstützte Dienstressource verweist, z. B. "resource.matchTag('env', 'dev')".

     Weitere Informationen zu bedingten Organisationsrichtlinien finden Sie unter Organisationsrichtlinie mit Tags festlegen.

   • Wenn Sie das Löschen einer Organisationsrichtlinie testen möchten, die eine benutzerdefinierte Einschränkung erzwingt, erstellen Sie eine JSON- oder YAML-Datei, die die Organisationsrichtlinie ohne festgelegte Regeln definiert, mit Ausnahme der Übernahme der Richtlinie von der übergeordneten Ressource:

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

     Ersetzen Sie Folgendes:

     • ORGANIZATION_ID durch Ihre Organisations-ID, z. B. 1234567890123.

     • Ersetzen Sie CONSTRAINT_NAME durch den Namen der benutzerdefinierten Einschränkung, die Sie testen möchten. Beispiel: custom.EnforceGKEBinaryAuthz

3. Führen Sie den Befehl policy-intelligence simulate orgpolicy aus, um die Änderung einer benutzerdefinierten Einschränkung, einer Organisationsrichtlinie oder beider zu simulieren:

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

   Ersetzen Sie Folgendes:

   • ORGANIZATION_ID: Ihre Organisations-ID, z. B. 1234567890123. Das Simulieren von Änderungen in mehreren Organisationen wird nicht unterstützt.

   • CONSTRAINT_PATH: Der vollständige Pfad zur benutzerdefinierten Einschränkung, die Sie erstellt oder aktualisiert haben. Beispiel: tmp/constraint.yaml Wenn Sie das Flag --policies festlegen, müssen Sie das Flag --custom-constraints nicht festlegen.

   • POLICY_PATH: Der vollständige Pfad zur Organisationsrichtlinie, die Sie erstellt oder aktualisiert haben. Beispiel: tmp/policy.yaml Wenn Sie das Flag --custom-constraints festlegen, müssen Sie das Flag --policies nicht festlegen.

Nach einigen Minuten gibt der Befehl eine Liste mit Ressourcen aus, die gegen die Änderungen an der benutzerdefinierten Einschränkung, der Organisationsrichtlinie oder beiden verstoßen würden.

Die Ergebnisse sind auch auf der Seite Simulationsverlauf der Google Cloud -Konsole verfügbar. Weitere Informationen zum Lesen der Ergebnisse finden Sie auf dieser Seite unter Ergebnisse des Richtliniensimulators.

Das folgende Beispiel zeigt eine Antwort für eine Organisationsrichtliniensimulation. Bei dieser Simulation wird eine benutzerdefinierte Einschränkung verwendet, die das Erstellen von Google Kubernetes Engine-Clusterressourcen einschränkt, bei denen die Binärautorisierung nicht aktiviert ist. Wenn in diesem Fall die vorgeschlagene Änderung angewendet wird, verstoßen zwei Clusterressourcen gegen die Richtlinie: orgpolicy-test-cluster im Projekt simulator-test-project und autopilot-cluster-1 im Projekt 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

Console

1. Rufen Sie in der Google Cloud Console die Seite Organisationsrichtlinien auf.

   Zu den Organisationsrichtlinien

2. Klicken Sie auf **Projekt auswählen und wählen Sie dann die Organisations-, Ordner- oder Projektressource aus, für die Sie die Organisationsrichtlinie bearbeiten möchten.

3. Wählen Sie in der Liste die verwaltete Einschränkung aus, für die Sie die Organisationsrichtlinie aktualisieren möchten. Auf der Seite Richtliniendetails sehen Sie die Quelle dieser Organisationsrichtlinie, die effektive Richtlinienauswertung für diese Ressource und weitere Details zur verwalteten Einschränkung.

4. Zum Aktualisieren der Organisationsrichtlinie für diese Ressource klicken Sie auf Richtlinie verwalten.

5. Wählen Sie auf der Seite Richtlinie bearbeiten die Option Richtlinie der übergeordneten Ressource überschreiben aus.

6. Klicken Sie auf Regel hinzufügen.

7. Wählen Sie im Abschnitt Erzwingung aus, ob die Erzwingung dieser Organisationsrichtlinie aktiviert oder deaktiviert werden soll.

8. Klicken Sie optional auf Bedingung hinzufügen, um die Organisationsrichtlinie von einem Tag abhängig zu machen. Wenn Sie einer Organisationsrichtlinie eine bedingte Regel hinzufügen, müssen Sie mindestens eine bedingungslose Regel hinzufügen. Andernfalls kann die Richtlinie nicht gespeichert werden. Weitere Informationen finden Sie unter Organisationsrichtlinie mit Tags festlegen.

9. Klicken Sie auf Änderungen testen.

Die Seite Simulationsverlauf wird angezeigt. Sie enthält eine Liste der Simulationen, die Sie in den letzten 14 Tagen ausgeführt haben. Weitere Informationen finden Sie auf dieser Seite unter Ergebnisse des Richtliniensimulators.

gcloud

1. Erstellen oder ändern Sie eine Organisationsrichtlinie, die eine verwaltete Einschränkung erzwingt.

   • Wenn Sie das Erstellen oder Aktualisieren einer Organisationsrichtlinie testen möchten, die eine verwaltete Einschränkung erzwingt, erstellen Sie eine JSON- oder YAML-Datei, in der die Organisationsrichtlinie definiert ist.

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

     Ersetzen Sie Folgendes:

     • RESOURCE_TYPE mit organizations, folders oder projects.

     • RESOURCE_ID mit Ihrer Organisations-ID, Ordner-ID, Projekt-ID oder Projektnummer, je nach Ressourcentyp, der in RESOURCE_TYPE angegeben ist.

     • Ersetzen Sie CONSTRAINT_NAME durch den Namen der verwalteten Einschränkung, die Sie testen möchten. Beispiel: iam.managed.disableServiceAccountKeyCreation

     • ENFORCEMENT_STATE mit true, um diese Organisationsrichtlinie zu erzwingen, wenn sie festgelegt ist, oder false, um sie zu deaktivieren, wenn sie festgelegt ist.

     Optional können Sie die Organisationsrichtlinie von einem Tag abhängig machen, indem Sie der rules einen condition-Block hinzufügen. Wenn Sie einer Organisationsrichtlinie eine bedingte Regel hinzufügen, müssen Sie mindestens eine bedingungsfreie Regel hinzufügen oder die Richtlinie kann nicht gespeichert werden. Weitere Informationen finden Sie unter Organisationsrichtlinie mit Tags festlegen.

   • Wenn Sie das Löschen einer Organisationsrichtlinie testen möchten, die eine verwaltete Einschränkung erzwingt, erstellen Sie eine JSON- oder YAML-Datei, in der die Organisationsrichtlinie ohne festgelegte Regeln definiert ist. Die Richtlinie wird nur von der übergeordneten Ressource übernommen:

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

   Ersetzen Sie Folgendes:

   • ORGANIZATION_ID durch Ihre Organisations-ID.

   • CONSTRAINT_NAME durch den Namen der verwalteten Einschränkung, die Sie löschen möchten. Beispiel: iam.managed.disableServiceAccountKeyCreation

2. Führen Sie den Befehl policy-intelligence simulate orgpolicy aus:

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

   Ersetzen Sie Folgendes:

   • ORGANIZATION_ID durch Ihre Organisations-ID, z. B. 1234567890123. Das Simulieren von Änderungen in mehreren Organisationen wird nicht unterstützt.

   • POLICY_PATH durch den vollständigen Pfad zur YAML-Datei Ihrer Organisationsrichtlinie.

   Nach einigen Minuten gibt der Befehl eine Liste mit Ressourcen aus, die gegen die Änderungen an der benutzerdefinierten Einschränkung, der Organisationsrichtlinie oder beiden verstoßen würden.

   Die Ergebnisse sind auch auf der Seite Simulationsverlauf der Google Cloud -Konsole verfügbar. Weitere Informationen zum Lesen der Ergebnisse finden Sie auf dieser Seite unter Ergebnisse des Richtliniensimulators.

Console

1. Wenn Sie die Ergebnisse von Policy Simulator für eine benutzerdefinierte Einschränkung erzwingen möchten, rufen Sie die Seite Simulationsverlauf auf.

   Zum Simulationsverlauf

2. Wählen Sie den Simulationsbericht für die benutzerdefinierte Einschränkung oder Organisationsrichtlinie aus, die Sie anwenden möchten.

3. Wenn dieser Simulationsbericht eine benutzerdefinierte Einschränkung enthält, klicken Sie auf Einschränkung speichern.

4. Wenn dieser Simulationsbericht Änderungen an höchstens einer Organisationsrichtlinie enthält, können Sie diese Organisationsrichtlinie als Probelaufrichtlinie anwenden, um das Verhalten in der Produktion ohne Risiken zu überwachen. Klicken Sie dazu auf Probelaufrichtlinie festlegen. Die Seite Richtliniendetails für die neue Organisationsrichtlinie wird angezeigt.

   Sie können die Organisationsrichtlinie sofort erzwingen, indem Sie auf expand_more und dann auf Richtlinie festlegen klicken.

gcloud

1. Wenn Sie eine benutzerdefinierte Einschränkung erzwingen möchten, müssen Sie sie einrichten, damit sie für Organisationsrichtlinien in Ihrer Organisation verfügbar ist. Verwenden Sie zum Einrichten einer benutzerdefinierten Einschränkung den Befehl gcloud org-policies set-custom-constraint:

   gcloud org-policies set-custom-constraint CONSTRAINT_PATH
   

   Ersetzen Sie CONSTRAINT_PATH durch den vollständigen Pfad zu Ihrer benutzerdefinierten Einschränkungsdatei. Beispiel: /home/user/customconstraint.yaml.

   Danach ist Ihre benutzerdefinierte Einschränkung in der Liste der Google Cloud Organisationsrichtlinien verfügbar.

2. Verwenden Sie den Befehl gcloud org-policies set-policy, um die Organisationsrichtlinie festzulegen:

   gcloud org-policies set-policy POLICY_PATH
   

   Ersetzen Sie POLICY_PATH durch den vollständigen Pfad zur YAML-Datei Ihrer Organisationsrichtlinie.

   Es kann bis zu 15 Minuten dauern, bis die Richtlinie wirksam wird.

Console

Wenn Sie die Google Cloud Konsole verwenden, können Sie die Policy Simulator-Ergebnisse als CSV-Datei speichern.

1. Wenn Sie die Ergebnisse von Policy Simulator speichern möchten, rufen Sie die Seite Simulationsverlauf auf.

   Zum Simulationsverlauf

2. Wählen Sie den Simulationsbericht aus, den Sie speichern möchten.

3. Klicken Sie auf upload Vollständige Ergebnisse exportieren.

gcloud

Wenn Sie die gcloud CLI verwenden, können Sie die Policy Simulator-Ergebnisse als JSON- oder YAML-Datei speichern.

Standardmäßig werden Testergebnisse in der Google Cloud CLI im YAML-Format ausgegeben. Um ein Testergebnis als YAML-Datei zu speichern, leiten Sie die Ausgabe des Befehls simulate orgpolicy beim Ausführen der Simulation um:

> FILENAME

Ersetzen Sie FILENAME durch einen Namen für die Ausgabedatei.

Um ein Testergebnis als JSON-Datei zu speichern, fügen Sie dem Befehl simulate orgpolicy beim Ausführen der Simulation das folgende Flag hinzu:

--format=json > FILENAME

Ersetzen Sie FILENAME durch einen Namen für die Ausgabedatei.