Tester les modifications apportées aux règles d'administration à l'aide de Policy Simulator

Console

1. Dans la console Google Cloud , accédez à la page Règles d'administration.

   Accéder à la page Règles d'administration

2. Dans le sélecteur d'organisation, sélectionnez la ressource de votre organisation.

3. Effectuez l'une des opérations suivantes :

   • Pour tester une nouvelle contrainte personnalisée, cliquez sur add Contrainte personnalisée.

   • Pour modifier une contrainte personnalisée existante, sélectionnez-la dans la liste de la page Règles d'administration, puis cliquez sur edit Modifier la contrainte.

4. Créez ou mettez à jour la contrainte personnalisée que vous souhaitez tester.

   1. Dans le champ Nom à afficher, saisissez un nom convivial pour la contrainte. Ce champ ne doit pas comporter plus de 200 caractères. N'utilisez pas d'informations permettant d'identifier personnellement l'utilisateur ni de données sensibles dans les noms à afficher, car elles pourraient être exposées dans des messages d'erreur.

   2. Dans la zone ID de contrainte, saisissez le nom souhaité pour votre nouvelle contrainte personnalisée. Une contrainte personnalisée doit commencer par custom. et ne peut inclure que des lettres majuscules, minuscules ou des chiffres, comme par exemple custom.disableGkeAutoUpgrade. La longueur maximale de ce champ est de 70 caractères, sans compter le préfixe, comme par exemple organizations/123456789/customConstraints/custom.. Veuillez n'inclure aucune information permettant d'identifier l'utilisateur ou donnée sensible dans l'ID de votre contrainte, car ces informations pourraient être divulguées dans les messages d'erreur.

      Une fois la contrainte personnalisée créée, vous ne pouvez plus modifier son ID.

   3. Dans la zone Description, saisissez pour la contrainte une description conviviale qui sera affichée dans un message d'erreur en cas de non-respect de la règle. Ce champ ne doit pas comporter plus de 2 000 caractères. Veuillez n'inclure aucune information permettant d'identifier l'utilisateur ou donnée sensible dans votre description, car ces informations pourraient être divulguées dans les messages d'erreur.

   4. Dans la zone Type de ressource, sélectionnez le nom de la ressource REST Google Cloudcontenant l'objet et le champ que vous souhaitez restreindre (par exemple, container.googleapis.com/NodePool). La plupart des types de ressources peuvent comporter un maximum de 20 contraintes personnalisées par ressource. Si vous essayez de créer une contrainte personnalisée pour une ressource qui a déjà atteint le nombre maximal de contraintes personnalisées, l'opération échoue.

   5. Dans la section Méthode d'application, indiquez si vous souhaitez appliquer la contrainte sur la méthode REST CREATE ou sur les méthodes REST CREATE et UPDATE. Les services Google Cloud ne sont pas tous compatibles avec les deux méthodes. Pour connaître les méthodes compatibles avec chaque service, recherchez le service dans la section Services compatibles.

   6. Pour définir une condition, cliquez sur edit Modifier la condition.

   7. Dans le panneau Ajouter une condition, créez une condition CEL faisant référence à une ressource de service acceptée, par exemple resource.management.autoUpgrade == false. Ce champ ne doit pas comporter plus de 1 000 caractères. Pour plus d'informations sur l'utilisation du langage CEL, consultez la page Common Expression Language. Pour en savoir plus sur les ressources de service que vous pouvez utiliser dans vos contraintes personnalisées, consultez Services compatibles avec les contraintes personnalisées.

   8. Cliquez sur Enregistrer.

   9. Dans la section Action, indiquez si vous souhaitez autoriser ou refuser la méthode évaluée si la condition que vous avez écrite est remplie.

      L'action de refus signifie que l'opération de création ou de mise à jour de la ressource est bloquée si la condition renvoie la valeur "true".

      L'action "Autoriser" signifie que l'opération de création ou de mise à jour de la ressource n'est autorisée que si la condition renvoie la valeur "true". Tous les autres cas, à l'exception de ceux explicitement regroupés dans la condition, sont bloqués.

5. Cliquez sur Tester la contrainte.

6. S'il s'agit d'une nouvelle contrainte, le volet Configurer la règle d'administration s'affiche. Pour définir une règle d'administration qui applique la contrainte personnalisée, procédez comme suit :

   1. Dans la zone Sélectionner le champ d'application, sélectionnez la ressource pour laquelle vous souhaitez tester la contrainte personnalisée.

   2. Cliquez sur Ignorer la règle parente.

   3. Cliquez sur Ajouter une règle.

   4. Dans la section Application, sélectionnez Activé.

   5. Pour rendre la règle d'administration conditionnelle sur un tag, cliquez sur Ajouter une condition. Si vous ajoutez une règle conditionnelle à une règle d'administration, vous devez ajouter au moins une règle non conditionnelle, sinon la règle ne pourra pas être enregistrée. Pour en savoir plus, consultez Définir une règle d'administration avec des tags.

   6. Cliquez sur OK, puis sur Continuer.

La page Historique des simulations s'affiche. Elle contient la liste des simulations que vous avez effectuées au cours des 14 derniers jours. Pour en savoir plus, consultez la section Résultats de Policy Simulator sur cette page.

gcloud

1. Pour tester l'application d'une contrainte personnalisée nouvelle ou modifiée, créez un fichier JSON ou YAML qui définit la contrainte personnalisée que vous souhaitez tester.

   Si vous souhaitez tester les modifications apportées à une contrainte personnalisée existante, vous pouvez utiliser la commande gcloud CLI organizations.customConstraints.get pour récupérer la représentation JSON ou YAML actuelle de la contrainte personnalisée, puis modifier ce fichier.

   Un fichier YAML qui définit une contrainte personnalisée ressemble à ce qui suit :

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

   Remplacez les éléments suivants :

   • ORGANIZATION_ID : ID de votre organisation (par exemple, 123456789).

   • CONSTRAINT_NAME : nom souhaité pour votre nouvelle contrainte personnalisée. Une contrainte personnalisée doit commencer par custom. et ne peut inclure que des lettres majuscules, minuscules ou des chiffres, comme par exemple custom.disableGkeAutoUpgrade. La longueur maximale de ce champ est de 70 caractères, sans compter le préfixe, comme par exemple organizations/123456789/customConstraints/custom..

   • RESOURCE_NAME : nom complet de la ressource RESTGoogle Cloud contenant l'objet et le champ que vous souhaitez restreindre. Par exemple, container.googleapis.com/NodePool. La plupart des types de ressources peuvent comporter jusqu'à 20 contraintes personnalisées par ressource. Si vous essayez de créer une contrainte personnalisée pour une ressource qui a déjà atteint le nombre maximal de contraintes personnalisées, l'opération échoue. Pour en savoir plus sur les ressources de service que vous pouvez utiliser dans vos contraintes personnalisées, consultez Services compatibles avec les contraintes personnalisées.

   • METHOD1,METHOD2 : liste des méthodes RESTful pour lesquelles la contrainte est appliquée. Il peut s'agir de CREATE, ou de CREATE et de UPDATE. Les services Google Cloud ne sont pas tous compatibles avec les deux méthodes. Pour connaître les méthodes compatibles avec chaque service, recherchez le service dans la section Services compatibles.

   • CONDITION : condition CEL faisant référence à une ressource de service compatible, par exemple "resource.management.autoUpgrade == false". Ce champ ne doit pas comporter plus de 1 000 caractères. Pour plus d'informations sur l'utilisation du langage CEL, consultez la page Common Expression Language.

   • ACTION : action à effectuer si la condition est remplie. Peut être défini sur ALLOW ou DENY.

     • L'action "Refuser" signifie que si la condition renvoie la valeur "true", l'opération de création ou de mise à jour de la ressource est bloquée.

     • L'action "Autoriser" signifie que si la condition renvoie la valeur "true", l'opération de création ou de mise à jour de la ressource est autorisée. Cela signifie également que tous les autres cas, à l'exception de celui explicitement regroupé dans la condition, sont bloqués.

   • DISPLAY_NAME : nom convivial de la contrainte. Ce champ ne doit pas comporter plus de 200 caractères.

   • DESCRIPTION : description conviviale de la contrainte, qui sera affichée dans un message d'erreur en cas de non-respect de la règle. La longueur maximale de ce champ est de 2 000 caractères. Pour en savoir plus sur la création de contraintes personnalisées, consultez Créer et gérer des contraintes personnalisées.

2. Créez ou modifiez une règle d'administration qui applique la contrainte personnalisée.

   • Pour tester l'application d'une contrainte personnalisée nouvelle ou mise à jour, créez un fichier JSON ou YAML qui définit la règle d'administration que vous souhaitez tester :

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

     Remplacez les éléments suivants :

     • ORGANIZATION_ID par l'ID de votre organisation, par exemple 1234567890123.

     • CONSTRAINT_NAME par le nom de la contrainte personnalisée que vous souhaitez tester. Exemple : custom.EnforceGKEBinaryAuthz.

   • Pour tester l'application d'une contrainte personnalisée de manière conditionnelle en fonction de l'existence d'un tag spécifique, créez un fichier JSON ou YAML qui définit la règle d'administration :

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

     Remplacez les éléments suivants :

     • ORGANIZATION_ID par l'ID de votre organisation, par exemple 1234567890123.

     • CONSTRAINT_NAME par le nom de la contrainte personnalisée que vous souhaitez tester. Exemple : custom.EnforceGKEBinaryAuthz.

     • CONDITION par une condition CEL faisant référence à une ressource de service acceptée, par exemple "resource.matchTag('env', 'dev')".

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

   • Pour tester la suppression d'une règle d'administration qui applique une contrainte personnalisée, créez un fichier JSON ou YAML qui définit la règle d'administration sans aucune règle définie, à l'exception de l'héritage de la règle à partir de sa ressource parente :

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

     Remplacez les éléments suivants :

     • ORGANIZATION_ID par l'ID de votre organisation, par exemple 1234567890123.

     • CONSTRAINT_NAME par le nom de la contrainte personnalisée que vous souhaitez tester. Exemple : custom.EnforceGKEBinaryAuthz.

3. Pour simuler la modification d'une contrainte personnalisée, d'une règle d'administration ou des deux, exécutez la commande policy-intelligence simulate orgpolicy :

   gcloud 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. Exemple : tmp/constraint.yaml. Si vous définissez l'option --policies, vous n'avez pas besoin de définir l'option --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'indicateur --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 enfreindraient les modifications apportées à la contrainte personnalisée, à la règle d'administration ou aux deux.

Les résultats sont également visibles sur la page Historique des simulations de la console Google Cloud . Pour savoir comment lire les résultats, consultez la section Résultats de Policy Simulator sur cette page.

Voici un exemple de réponse pour une simulation de règle d'organisation. 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 sous le projet simulator-test-project et autopilot-cluster-1 sous 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

Console

1. Dans la console Google Cloud , accédez à la page Règles d'administration.

   Accéder à la page Règles d'administration

2. Cliquez sur **Sélectionner un projet, puis sélectionnez la ressource d'organisation, de dossier ou de projet pour laquelle vous souhaitez modifier la règle d'administration.

3. Dans la liste, sélectionnez la contrainte gérée pour laquelle vous souhaitez mettre à jour la règle d'administration. Sur la page Détails de la règle, vous pouvez voir la source de cette règle d'administration, l'évaluation de la règle effective sur cette ressource et d'autres détails sur la contrainte gérée.

4. Pour mettre à jour la règle d'administration pour cette ressource, cliquez sur Gérer la règle.

5. Sur la page Modifier la règle, sélectionnez Remplacer la règle parente.

6. Cliquez sur Ajouter une règle.

7. Dans la section Application, indiquez si l'application de cette règle d'administration doit être activée ou désactivée.

8. Pour rendre la règle d'administration conditionnelle sur un tag, cliquez sur Ajouter une condition. Si vous ajoutez une règle conditionnelle à une règle d'administration, vous devez ajouter au moins une règle non conditionnelle, sinon la règle ne pourra pas être enregistrée. Pour en savoir plus, consultez Définir une règle d'administration avec des tags.

9. Cliquez sur Tester les modifications.

La page Historique des simulations s'affiche. Elle contient la liste des simulations que vous avez effectuées au cours des 14 derniers jours. Pour en savoir plus, consultez la section Résultats de Policy Simulator sur cette page.

gcloud

1. Créez ou modifiez une règle d'administration qui applique une contrainte gérée.

   • Pour tester la création ou la mise à jour d'une règle d'administration qui applique une contrainte gérée, créez un fichier JSON ou YAML qui définit la règle d'administration.

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

     Remplacez les éléments suivants :

     • RESOURCE_TYPE avec organizations, folders ou projects.

     • RESOURCE_ID avec l'ID de votre organisation, l'ID du dossier, l'ID du projet ou le numéro du projet, selon le type de ressource spécifié dans RESOURCE_TYPE.

     • CONSTRAINT_NAME par le nom de la contrainte gérée que vous souhaitez tester. Exemple : iam.managed.disableServiceAccountKeyCreation.

     • ENFORCEMENT_STATE avec true pour appliquer cette règle d'administration lorsqu'elle est définie, ou false pour la désactiver lorsqu'elle est définie.

     Pour rendre la règle d'administration conditionnelle sur un tag, ajoutez un bloc condition à rules. Si vous ajoutez une règle conditionnelle à une règle d'administration, vous devez ajouter au moins une règle inconditionnelle, sinon la règle ne pourra pas être enregistrée. Pour en savoir plus, consultez Définir une règle d'administration avec des tags.

   • Pour tester la suppression d'une règle d'administration qui applique une contrainte gérée, créez un fichier JSON ou YAML qui définit la règle d'administration sans aucune règle définie, à l'exception de l'héritage de la règle à partir de sa ressource parente :

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

   Remplacez les éléments suivants :

   • ORGANIZATION_ID par votre ID d'organisation

   • CONSTRAINT_NAME par le nom de la contrainte gérée que vous souhaitez supprimer. Exemple : iam.managed.disableServiceAccountKeyCreation.

2. Exécutez la commande policy-intelligence simulate orgpolicy :

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

   Remplacez les éléments suivants :

   • ORGANIZATION_ID par l'ID de votre organisation, par exemple 1234567890123. Il n'est pas possible de simuler des modifications dans plusieurs organisations.

   • POLICY_PATH par le chemin d'accès complet au fichier YAML de votre règle d'administration.

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

   Les résultats sont également visibles sur la page Historique des simulations de la console Google Cloud . Pour savoir comment lire les résultats, consultez la section Résultats de Policy Simulator sur cette page.

Console

1. Pour appliquer les résultats de Policy Simulator à une contrainte personnalisée, accédez à la page Historique des simulations.

   Accéder à l'historique des simulations

2. Sélectionnez le rapport de simulation pour la contrainte personnalisée ou la règle d'administration que vous souhaitez appliquer.

3. Si ce rapport de simulation inclut une contrainte personnalisée, cliquez sur Enregistrer la contrainte.

4. Si ce rapport de simulation inclut des modifications apportées à une seule règle d'administration, vous pouvez appliquer cette règle en tant que règle en mode dry run pour surveiller le comportement en production sans introduire de risque. Pour ce faire, cliquez sur Définir une règle en mode dry run. La page Détails de la règle du nouvel ensemble de règles d'administration s'affiche.

   Vous pouvez appliquer immédiatement la règle d'administration en cliquant sur expand_more, puis sur Définir la règle.

gcloud

1. Pour appliquer une contrainte personnalisée, vous devez la configurer de sorte qu'elle soit disponible pour 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. Exemple :/home/user/customconstraint.yaml

   Une fois l'opération terminée, votre contrainte personnalisée est ajoutée à la liste des règles d'administration Google Cloud .

2. Pour définir la règle d'administration, 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 votre règle d'administration.

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

Console

Si vous utilisez la console Google Cloud , vous pouvez enregistrer les résultats de Policy Simulator sous forme de fichier CSV.

1. Pour enregistrer les résultats de Policy Simulator, accédez à la page Historique des simulations.

   Accéder à l'historique des simulations

2. Sélectionnez le rapport de simulation que vous souhaitez enregistrer.

3. Cliquez sur upload Exporter les résultats complets.

gcloud

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 affichés au format YAML. Pour enregistrer un résultat de test sous forme de fichier YAML, redirigez la sortie 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 les résultats d'un test sous forme de fichier JSON, ajoutez l'option suivante à la commande simulate orgpolicy lors de l'exécution de la simulation :

--format=json > FILENAME

Remplacez FILENAME par le nom du fichier de sortie.