Gérer les ressources à l'aide de contraintes personnalisées

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page explique comment utiliser les contraintes personnalisées du service de règles d'administration pour restreindre des opérations spécifiques sur les ressources Google Cloud suivantes:

• cloudresourcemanager.googleapis.com/Project
• cloudresourcemanager.googleapis.com/Folder

Pour en savoir plus sur les règles d'administration, consultez la section Règles d'administration personnalisées.

À propos des règles et des contraintes de l'organisation

Le Google Cloud service de règles d'administration vous offre un contrôle centralisé et automatisé sur les ressources de votre organisation. En tant qu'administrateur des règles d'administration, vous pouvez définir une règle d'administration, c'est-à-dire un ensemble de restrictions appelées Contraintes qui s'appliquent aux ressourcesGoogle Cloud et aux descendants de ces ressources dans la Hiérarchie des ressourcesGoogle Cloud . Vous pouvez appliquer des règles d'administration au niveau d'une organisation, d'un dossier ou d'un projet.

Les règles d'administration fournissent des contraintes prédéfinies pour divers services Google Cloud . Toutefois, si vous souhaitez exercer un contrôle plus précis et personnalisable sur les champs spécifiques restreints dans vos règles d'administration, vous pouvez également créer des contraintes personnalisées et les utiliser dans une règle d'administration.

Héritage des règles

Par défaut, les règles d'administration sont héritées par les descendants des ressources sur lesquelles vous les appliquez. Par exemple, si vous appliquez une stratégie au niveau d'un dossier, Google Cloud l'applique à tous les projets du dossier. Pour mieux comprendre ce comportement et savoir comment le modifier, consultez la page Règles d'évaluation hiérarchique.

Avantages

Pour la sécurité, la conformité et la gouvernance, vous pouvez utiliser des règles d'administration personnalisées de la manière suivante:

• Gérer les modèles de dénomination des projets: vous pouvez créer une contrainte personnalisée sur l'ID du projet. Par exemple, dans un dossier de ressources de préproduction, n'autorisez les opérations de création et de mise à jour d'un projet que si l'ID de projet commence par staging-.
• Limiter la mutation de projets et de dossiers sécurisés: vous pouvez créer une contrainte personnalisée pour refuser les mises à jour de projets et de dossiers si le parent est un dossier ou une organisation sécurisé.

Limites

• Les opérations de création ou de mise à jour des ressources Apps Script, Firebase ou Contact Center Solution peuvent échouer si une contrainte personnalisée a été définie sur des dossiers ou des projets. Dans ce cas, vérifiez les conditions des contraintes personnalisées qui provoquent l'échec. Assurez-vous que ces restrictions sont mises à jour, puis réessayez l'opération ayant échoué.
• Comme pour toutes les contraintes des règles d'administration, les modifications apportées aux règles ne s'appliquent pas rétroactivement aux instances existantes.
• La création de projets et de dossiers dans la console Google Cloud peut ne pas indiquer la raison spécifique du message d'erreur PERMISSION_DENIED. Pour confirmer les détails des contraintes spécifiques à l'origine de l'échec, vous pouvez consulter les journaux d'audit.

Avant de commencer

Rôles requis

Pour obtenir les autorisations nécessaires pour gérer des règles d'administration personnalisées, demandez à votre administrateur de vous accorder le rôle IAM Administrateur des règles d'administration (roles/orgpolicy.policyAdmin) dans la ressource d'organisation. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

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

Créer une contrainte personnalisée

Une contrainte personnalisée est définie dans un fichier YAML, qui spécifie les ressources, méthodes, conditions et actions compatibles avec le service sur lequel vous appliquez la règle d'administration. Les conditions de vos contraintes personnalisées sont définies à l'aide du langage CEL (Common Expression Language). Pour en savoir plus sur la création de conditions dans des contraintes personnalisées à l'aide du CEL, consultez la section CEL de la page Créer et gérer des contraintes personnalisées.

Pour créer une contrainte personnalisée, créez un fichier YAML au format suivant:

name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes:
- RESOURCE_NAME
methodTypes:
- CREATE
- UPDATE
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. Exemple : custom.allowProjectForXDepartmentNameOnly. La longueur maximale de ce champ est de 70 caractères.

• RESOURCE_NAME: nom complet de la ressourceGoogle Cloud contenant l'objet et le champ que vous souhaitez restreindre. Par exemple, cloudresourcemanager.googleapis.com/Project.

• CONDITION : condition CEL écrite pour une représentation d'une ressource de service acceptée. Ce champ ne doit pas comporter plus de 1 000 caractères. Consultez la section Ressources compatibles pour en savoir plus sur les ressources disponibles pour l'écriture de conditions. Par exemple, "resource.projectId.startsWith(\"XDepartment\")".

• ACTION : action à effectuer si la condition est remplie. Les valeurs possibles sont ALLOW et DENY.

• 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. Ce champ ne doit pas comporter plus de 2 000 caractères.

Pour en savoir plus sur la création d'une contrainte personnalisée, consultez la page Définir des contraintes personnalisées.

Configurer une contrainte personnalisée

gcloud org-policies set-custom-constraint CONSTRAINT_PATH

gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

Appliquer une règle d'administration personnalisée

      name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
      spec:
        rules:
        - enforce: true
    

    gcloud org-policies set-policy POLICY_PATH
    

Tester la règle d'administration personnalisée

L'exemple suivant crée une contrainte et une règle personnalisées qui exigent que tous les ID de projet commencent par dev_ dans votre organisation.

Avant de commencer, identifiez l'ID de votre organisation.

Créer la contrainte

1. Pour définir une contrainte qui refuse toutes les créations et mises à jour de projets si l'ID du projet ne commence pas par dev_, créez constraint-allow-dev-projects.yaml avec le contenu suivant:

   name: organizations/ORGANIZATION_ID/customConstraints/custom.allowProjectForDevIdOnly
   resourceTypes:
   - cloudresourcemanager.googleapis.com/Project
   methodTypes:
   - CREATE
   - UPDATE
   condition: "resource.projectId.startsWith(\"dev_\")"
   actionType: ALLOW
   displayName: Allow dev_ projects
   description: All projects in the org should start with dev_.
   

   Remplacez ORGANIZATION_ID par votre ID d'organisation.

2. Appliquez la contrainte :

   gcloud org-policies set-custom-constraint ~/constraint-allow-dev-projects.yaml
   

3. Vérifiez que la contrainte existe :

   gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
   

   Le résultat ressemble à ce qui suit :

   CUSTOM_CONSTRAINT                ACTION_TYPE  METHOD_TYPES   RESOURCE_TYPES                                      DISPLAY_NAME
   custom.allowProjectForDevIdOnly  ALLOW        CREATE,UPDATE  cloudresourcemanager.googleapis.com/Project   Allow dev_ projects
   ...
   

Créer la règle

1. Créez le fichier policy-enable-dev-projects.yaml avec la stratégie suivante:

   Name: organizations/ORGANIZATION_ID/policies/custom.allowProjectForDevIdOnly
   spec:
     rules:
     - enforce: true
   

   Remplacez ORGANIZATION_ID par votre ID d'organisation.

2. Appliquez la règle :

   gcloud org-policies set-policy ~/policy-enable-dev-projects.yaml
   

3. Vérifiez que la règle existe :

   gcloud org-policies list --organization=ORGANIZATION_ID
   

   Le résultat ressemble à ce qui suit :

   CONSTRAINT                        LIST_POLICY    BOOLEAN_POLICY    ETAG
   custom.allowProjectForDevIdOnly   -              SET               COCsm5QGENiXi2E=
   

Une fois la règle appliquée, Google Cloud prend environ deux minutes pour commencer à l'appliquer.

Tester la stratégie

Créez un projet avec l'ID de projet sampleDemoProject dans l'organisation:

gcloud projects create sampleDemoProject \
    --organization=ORGANIZATION_ID

Le résultat est le suivant :

PERMISSION_DENIED: The caller does not have permission

Exemples de règles d'administration personnalisées pour des cas d'utilisation courants

Le tableau suivant fournit la syntaxe de certaines contraintes personnalisées pour les cas d'utilisation courants:

      name: organizations/ORGANIZATION_ID/customConstraints/custom.disableNewProjectInSecureAdminFolder
      resourceTypes:
      - cloudresourcemanager.googleapis.com/Project
      methodTypes:
      - CREATE
      condition: "resource.parent == "organizations/1234""
      actionType: DENY
      displayName: Disable new project creation in the secure admin folder
      description: Do not allow creation of new projects in the secure folders.
      

      name: organizations/ORGANIZATION_ID/customConstraints/custom.disableFolderCreation
      resourceTypes:
      - cloudresourcemanager.googleapis.com/Folder
      methodTypes:
      - CREATE
      condition: "resource.parent.startsWith("folders")"
      actionType: DENY
      displayName: Disable creation of a folder inside another folder
      description: Do not allow creation of a folder within another folder when
                   the resource hierarchy is set to a maximum value of 1.
      

Ressources compatibles avec Resource Manager

Étape suivante

• En savoir plus sur le service de règles d'administration
• Découvrez comment créer et gérer des règles d'administration.
• Consultez la liste complète des contraintes prédéfinies liées aux règles d'administration.