Compatibilité des dossiers dans les périmètres de service

La fonctionnalité d'appartenance basée sur les dossiers dans VPC Service Controls vous permet de définir des périmètres de service avec des dossiers Google Cloud comme membres. Cette fonctionnalité vous permet de sécuriser une hiérarchie de dossiers complète avec une seule configuration de périmètre. Elle réduit ainsi le surcoût administratif lié à la gestion des périmètres à grande échelle.

Ce document explique comment fonctionne la compatibilité des dossiers dans les périmètres et aborde les points suivants :

  • Concepts de base, comportements et avantages de l'utilisation de dossiers dans les périmètres.

  • Interactions entre l'appartenance basée sur les dossiers, les ressources imbriquées et les règles de hiérarchie des ressources telles que l'héritage et la priorité d'évaluation.

  • Découvrez comment rechercher les périmètres configurés pour les projets et les dossiers.

  • Bonnes pratiques et limites connues pour l'utilisation de cette fonctionnalité.

À propos de l'appartenance à un dossier dans les périmètres

Un Google Cloud dossier peut contenir plusieurs projets, d'autres dossiers ou une combinaison des deux. Bien que vous puissiez ajouter des projets individuels dans un dossier à un périmètre de service, nous vous recommandons d'ajouter plutôt le dossier parent. Lorsque vous spécifiez un dossier comme ressource protégée lorsque vous créez un périmètre, VPC Service Controls inclut toutes les ressources de ce dossier, telles que les projets et les dossiers imbriqués.

Lorsque vous ajoutez des projets à un dossier que vous avez configuré dans un périmètre, VPC Service Controls ajoute automatiquement ces projets au même périmètre. Vous n'avez pas besoin de mettre à jour la configuration du périmètre pour inclure ces projets. De même, lorsque vous supprimez des projets du dossier, VPC Service Controls les supprime automatiquement du périmètre.

Dossiers imbriqués et héritage

VPC Service Controls restreint toutes les ressources d'un dossier que vous avez configuré dans un périmètre, comme les dossiers imbriqués et leurs ressources. Lorsque vous ajoutez un dossier à un périmètre, VPC Service Controls restreint automatiquement tous les projets de ce dossier et de ses sous-dossiers.

Priorité de l'évaluation de l'appartenance aux ressources

Une ressource Google Cloud ne peut être protégée que par un seul périmètre de service régulier en mode forcé et un seul en mode de simulation. Si une ressource ou ses dossiers parents sont associés à plusieurs périmètres, l'association de niveau le plus bas dans la hiérarchie des ressources détermine le périmètre effectif.

VPC Service Controls évalue la priorité indépendamment pour le mode appliqué et le mode dry run :

  • Priorité du mode forcé : le périmètre forcé effectif est déterminé par la ressource la plus basse de la hiérarchie (le projet lui-même ou son dossier ancêtre le plus proche) qui est explicitement attribuée à un périmètre forcé.
  • Priorité du mode dry run : le périmètre de dry run effectif est déterminé par la ressource la plus basse de la hiérarchie qui est explicitement attribuée à un périmètre de dry run ou implicitement héritée d'une ressource appliquée explicitement.

La configuration d'un périmètre de dry run pour un projet ou un sous-dossier ne désactive ni ne remplace un périmètre forcé configuré sur un dossier ancêtre.

Exemples de priorité

  • Exemple 1 (Remplacement direct du projet en mode forcé) : si vous configurez un dossier parent (folders/1) dans un périmètre forcé (sp1) et que vous configurez explicitement un projet dans ce dossier (projects/1) dans un autre périmètre forcé (sp2), projects/1 est protégé par sp2. L'attribution directe de projet prévaut sur l'héritage de dossier. Tous les autres projets de folders/1 (comme projects/2) restent protégés par sp1 grâce à l'héritage des dossiers.

  • Exemple 2 (Héritage de dossier en mode de simulation) : Lorsque vous configurez un dossier (folders/1) dans un périmètre de service en mode de simulation, tous les projets de ce dossier (projects/1 et projects/2) héritent de la configuration du périmètre en mode dry run (sp1), sauf si elle est explicitement désactivée. L'héritage du mode dry run se comporte de la même manière que l'héritage du mode forcé, sauf si une ressource imbriquée est explicitement configurée avec un périmètre de dry run différent.

  • Exemple 3 (Évaluation indépendante des périmètres forcés et en mode simulation) : VPC Service Controls évalue les associations forcées et en mode simulation de manière indépendante. Si vous configurez un dossier parent (folders/1) dans un périmètre appliqué (sp1) et que vous attribuez explicitement un projet de ce dossier (projects/1) à un périmètre en mode simulation (sp2), projects/1 reste protégé par sp1 en mode appliqué tout en étant évalué en mode de simulation par sp2. L'attribution d'un projet à un périmètre de dry run ne remplace ni ne désactive le périmètre forcé du dossier parent.

  • Exemple 4 (Hiérarchie de dossiers à plusieurs niveaux et priorité des sous-dossiers) : dans une hiérarchie de dossiers à plusieurs niveaux, VPC Service Controls évalue la priorité à chaque niveau de la hiérarchie. Si un dossier ancêtre (folders/2) est configuré dans un périmètre appliqué (sp1), tous les projets qu'il contient (projects/1 et projects/2) héritent de l'application sp1. Lorsque des périmètres de dry run sont attribués à différents niveaux (par exemple, en attribuant l'ancêtre folders/2 au périmètre de dry run sp2 et le projet projects/2 (dans le sous-dossier folders/1) au périmètre de dry run sp1), chaque projet hérite de la configuration de dry run de son ancêtre le plus proche. Par conséquent, projects/1 est évalué lors du dry run sp2, mais projects/2 est évalué lors du dry run sp1.

Rechercher les périmètres configurés effectifs

Étant donné que les ressources peuvent hériter de la protection des périmètres des dossiers ancêtres, vous pouvez utiliser la méthode LookupConfiguredServicePerimeter pour identifier les périmètres de service qui protègent un projet ou un dossier.

L'API renvoie les éléments suivants :

  • servicePerimeter : nom complet du périmètre appliqué effectif.
  • servicePerimeterDryRun : nom complet du périmètre de simulation effectif.
  • restrictedResource : ressource spécifique (projet ou dossier) à laquelle le périmètre forcé est directement associé.
  • restrictedResourceDryRun : ressource spécifique à laquelle le périmètre d'exécution à sec est directement associé.

Pour en savoir plus, consultez Rechercher les périmètres configurés.

Exclusion de projets des périmètres

Pour exclure un projet d'un périmètre au niveau du dossier, attribuez-le explicitement à un périmètre distinct qui ne restreint aucun service et autorise tout le trafic entrant et sortant. Étant donné que les configurations de projet explicites sont prioritaires par rapport aux périmètres au niveau du dossier, le projet est exclu du périmètre du dossier.

Pour savoir comment mettre à jour les périmètres, consultez Mettre à jour un périmètre de service.

Règles limitées

Les périmètres de service d'une règle à portée limitée ne restreignent que les ressources qui existent dans le champ d'application de cette règle. Pour qu'un dossier soit inclus en tant que membre dans un périmètre limité, la stratégie d'accès doit être limitée à ce dossier ou à un de ses ancêtres (par exemple, un dossier parent ou l'organisation).

Bonnes pratiques

Consultez les bonnes pratiques suivantes lorsque vous gérez des périmètres basés sur des dossiers.

Migration sécurisée des projets vers des périmètres de dossiers

Lorsque vous passez d'une appartenance explicite à un projet à une appartenance basée sur un dossier, suivez ces étapes pour éviter toute interruption involontaire de l'application du périmètre :

  1. Ajoutez le dossier parent cible au périmètre de service.
  2. Déplacez les projets sous ce dossier parent dans la hiérarchie des ressources.
  3. Patientez au moins 48 heures : conservez les entrées de projet explicites dans la configuration du périmètre pendant au moins 48 heures. Cette période d'attente permet à la propagation de la hiérarchie des ressources de se terminer dans tous les systèmes.
  4. Supprimez les configurations de projet explicites du périmètre. Les projets restent protégés grâce à l'héritage des dossiers.

Déplacements dans la hiérarchie

Le déplacement de dossiers ou de projets modifie leur protection de périmètre effective. Pour éviter les refus d'accès inattendus, coordonnez tous les déplacements dans la hiérarchie avec votre administrateur Resource Manager.

Si vous déplacez des projets que vous avez configurés dans un périmètre vers un autre dossier et que vous ajoutez ce dossier au même périmètre, vous devez conserver les configurations d'appartenance explicite aux projets existantes dans le périmètre pendant au moins 48 heures. Ce délai d'attente permet la propagation de la hiérarchie des ressources et évite les problèmes d'application inattendus du périmètre lorsque vous supprimez les configurations de projet explicites du périmètre.

Limites

  • L'abonnement basé sur les dossiers n'est pas compatible avec les liaisons de périmètre. Les liaisons de périmètre n'acceptent que les ressources de projet.

  • VPC Service Controls n'est pas compatible avec les ressources d'API au niveau du dossier.

  • En raison d'un problème connu, la configuration d'un projet de réseau VPC en tant que ressource protégée dans un dossier de remplacement du périmètre en mode simulation remplace l'application basée sur les dossiers. Si un projet réseau est explicitement ajouté à un périmètre de dry run, il perd la protection du périmètre forcé héritée de ses dossiers ancêtres.

  • L'appartenance à un dossier n'est pas compatible avec les API nonGoogle Cloud et les périmètres configurés avec allowed_service_patterns. Pour autoriser l'accès à ces modèles de service, les projets ou réseaux VPC d'origine doivent être ajoutés explicitement au périmètre, plutôt que d'être hérités d'un dossier.

Étapes suivantes