Tester les modifications apportées aux règles d'administration avec Policy Simulator

Policy Simulator pour les règles d'administration vous permet de prévisualiser l'impact d'une nouvelle contrainte personnalisée ou d'une nouvelle règle d'administration qui applique une contrainte personnalisée avant qu'elle ne soit appliquée à votre environnement de production. Policy Simulator fournit une liste des ressources qui enfreignent la règle proposée avant qu'elle ne soit appliquée. Vous pouvez ainsi reconfigurer ces ressources, demander des exceptions ou modifier le champ d'application de votre règle d'administration, le tout sans perturber vos développeurs ni désactiver votre environnement.

Cette page explique comment tester une modification apportée à une règle d'administration à l'aide de Policy Simulator. Il explique également comment interpréter les résultats de la simulation et comment appliquer la règle d'administration testée si vous le souhaitez.

Avant de commencer

Dans la Google Cloud CLI, définissez le projet que vous souhaitez utiliser pour effectuer des appels d'API:

gcloud config set project PROJECT_ID

Remplacez PROJECT_ID par le nom ou l'ID du projet.
Activer les API Policy Simulator and Resource Manager.
Activer les API
Facultatif: Consultez une présentation du service de règles d'administration.

Rôles requis

Pour obtenir les autorisations nécessaires pour exécuter des simulations et accéder aux simulations, demandez à votre administrateur de vous attribuer le rôle IAM Administrateur du simulateur OrgPolicy (roles/policysimulator.orgPolicyAdmin) au niveau de l'organisation. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Ce rôle prédéfini contient les autorisations requises pour exécuter des simulations et y accéder. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour exécuter des simulations et y accéder:

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

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Tester un changement de règle

Vous pouvez tester la modification d'une contrainte personnalisée, d'une règle d'administration qui applique une contrainte personnalisée, ou des deux à la fois.

Pour tester une contrainte personnalisée, créez un fichier JSON ou YAML définissant la contrainte personnalisée que vous souhaitez tester.

Par exemple, une contrainte personnalisée qui limite la création de ressources de cluster Google Kubernetes Engine lorsque l'autorisation binaire n'est pas activée doit se présenter comme suit:
```
name: "organizations/ORGANIZATION_ID/customConstraints/custom.EnforceGKEBinaryAuthz"
resource_types: "container.googleapis.com/Cluster"
method_types: CREATE
condition: "resource.binaryAuthorization.enabled == true"
action_type: ALLOW
```
Remplacez ORGANIZATION_ID par l'ID de votre organisation, par exemple 1234567890123.

Pour en savoir plus sur la création de contraintes personnalisées, consultez la page Créer et gérer des contraintes personnalisées.
Pour tester une règle d'administration qui applique une contrainte personnalisée, créez un fichier JSON ou YAML définissant la règle d'administration que vous souhaitez tester.

Par exemple, une règle d'administration qui limite la création de ressources de cluster Google Kubernetes Engine pour lesquelles l'autorisation binaire n'est pas activée doit se présenter comme suit:
```
name: "organizations/ORGANIZATION_ID/policies/custom.EnforceGKEBinaryAuthz"
spec:
    rules:
    - enforce: true
```
Remplacez ORGANIZATION_ID par l'ID de votre organisation, par exemple 1234567890123.
Pour tester une règle d'administration qui applique de manière conditionnelle une contrainte personnalisée basée sur l'existence d'un tag particulier, créez un fichier JSON ou YAML définissant la règle d'administration que vous souhaitez tester.

Par exemple, la règle d'administration suivante limite la création de ressources de cluster Google Kubernetes Engine lorsque l'autorisation binaire n'est pas activée, sauf sur les ressources associées au tag env=dev.
```
name: "organizations/ORGANIZATION_ID/policies/custom.EnforceGKEBinaryAuthz"
spec:
    rules:
    - condition:
        expression: resource.matchTag('env', 'dev')
      enforce: false
    - enforce: true
```
Remplacez ORGANIZATION_ID par l'ID de votre organisation, tel que 1234567890123.

Pour en savoir plus sur les règles d'administration conditionnelles, consultez la page Définir une règle d'administration avec des tags.

Exécutez la commande suivante pour simuler la modification de la contrainte personnalisée, de la règle d'administration ou des deux:

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

Remplacez les éléments suivants :

ORGANIZATION_ID : ID de votre organisation (par exemple, 1234567890123). Il n'est pas possible de simuler des modifications dans plusieurs organisations.
CONSTRAINT_PATH: chemin d'accès complet à la contrainte personnalisée que vous avez créée ou mise à jour. Par exemple, tmp/constraint.yaml. Si vous définissez l'option --policies, vous n'avez pas besoin de définir l'indicateur --custom-constraints.
POLICY_PATH: chemin d'accès complet à la règle d'administration que vous avez créée ou mise à jour. Par exemple, tmp/policy.yaml. Si vous définissez l'option --custom-constraints, vous n'avez pas besoin de définir l'indicateur --policies.

Après quelques minutes, la commande affiche la liste des ressources qui ne respecteraient pas les modifications apportées à la contrainte personnalisée, à la règle d'administration ou aux deux.

Voici un exemple de réponse pour une simulation de règle d'administration. Cette simulation implique une contrainte personnalisée qui limite la création de ressources de cluster Google Kubernetes Engine lorsque l'autorisation binaire n'est pas activée. Dans ce cas, si la modification proposée était appliquée, deux ressources de cluster enfreindraient la règle: orgpolicy-test-cluster pour le projet simulator-test-project et autopilot-cluster-1 pour le projet 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

Appliquer une modification de stratégie testée

Après avoir testé votre contrainte personnalisée, votre règle d'administration ou les deux, vous pouvez configurer la contrainte personnalisée et appliquer la règle d'administration à l'aide des processus normaux.

Pour appliquer une contrainte personnalisée, vous devez la configurer de sorte qu'elle soit disponible dans les règles d'administration'administration de votre organisation. Pour configurer une contrainte personnalisée, utilisez la commande gcloud org-policies set-custom-constraint:
```
gcloud org-policies set-custom-constraint CONSTRAINT_PATH
```
Remplacez CONSTRAINT_PATH par le chemin d'accès complet à votre fichier de contrainte personnalisée. Par exemple, /home/user/customconstraint.yaml.

Une fois l'opération terminée, votre contrainte personnalisée apparaît dans votre liste de règles d'administration Google Cloud.
Pour appliquer une règle d'administration contenant une contrainte personnalisée, utilisez la commande gcloud org-policies set-policy:
```
gcloud org-policies set-policy POLICY_PATH
```
Remplacez POLICY_PATH par le chemin d'accès complet au fichier YAML de règle d'administration.

La prise en compte de la règle peut prendre jusqu'à 15 minutes.

Enregistrer les résultats de simulation

Si vous utilisez gcloud CLI, vous pouvez enregistrer les résultats de Policy Simulator sous forme de fichiers JSON ou YAML.

Par défaut, les résultats des tests dans Google Cloud CLI sont générés au format YAML. Pour enregistrer un résultat de test sous forme de fichier YAML, redirigez le résultat de la commande simulate orgpolicy lors de l'exécution de la simulation:

> FILENAME

Remplacez FILENAME par le nom du fichier de sortie.

Pour enregistrer un résultat de test sous forme de fichier JSON, ajoutez l'indicateur suivant à la commande simulate orgpolicy lors de l'exécution de la simulation:

--format=json > FILENAME