Présentation du VPC partagé

Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau VPC commun, afin que ces ressources puissent communiquer entre elles de manière sécurisée et efficace en utilisant les adresses IP internes de ce réseau. Lorsque vous utilisez un VPC partagé, vous désignez un projet en tant que projet hôte et vous lui associez un ou plusieurs projets de service. Les réseaux VPC du projet hôte sont appelés réseaux VPC partagés. Les ressources éligibles des projets de service peuvent utiliser des sous-réseaux du réseau VPC partagé.

Un réseau VPC partagé permet aux administrateurs d'une organisation de déléguer des responsabilités administratives, comme la création ou la gestion d'instances, à des administrateurs de projet de service tout en conservant un contrôle centralisé sur les ressources réseau, telles que les sous-réseaux, les routes et les pare-feu. Ce modèle permet aux organisations d'effectuer les tâches suivantes :

  • Mettre en œuvre le principe du moindre privilège en tant que bonne pratique de sécurité pour l'administration, l'audit et le contrôle des accès réseau. Les administrateurs de VPC partagé peuvent déléguer certaines tâches d'administration réseau aux administrateurs réseau et sécurité du réseau VPC partagé, sans pour autant autoriser les administrateurs de projet de service à effectuer des modifications ayant une incidence sur le réseau. Les administrateurs de projet de service peuvent uniquement créer et gérer des instances utilisant le réseau VPC partagé. Reportez-vous à la section Administrateurs et IAM pour plus de détails.
  • Appliquer et mettre en œuvre des stratégies de contrôle d'accès cohérentes à l'échelle du réseau pour différents projets de service de l'organisation tout en déléguant des responsabilités administratives. Par exemple, un administrateur de projet de service peut être administrateur d'instances Compute au sein de son projet, ce qui lui permet de créer et de supprimer des instances utilisant des sous-réseaux approuvés au sein du projet hôte du VPC partagé.
  • Utiliser des projets de service pour séparer les différents centres budgétaires ou centres de coûts internes. Reportez-vous à la section Facturation pour plus de détails.

Concepts

Organisations, dossiers et projets

Un VPC partagé connecte les projets définis au sein d'une même organisation. Le projet hôte et les projets de service participant à un VPC partagé ne peuvent pas appartenir à des organisations distinctes. Des projets liés peuvent se trouver dans le même dossier ou dans des dossiers différents. Toutefois, s'ils se trouvent dans des dossiers différents, l'administrateur doit disposer des droits d'administrateur de VPC partagé sur chacun des deux dossiers. Pour en savoir plus sur les organisations, les dossiers et les projets, consultez la documentation relative à la hiérarchie des ressources GCP.

Un projet participant à un VPC partagé est soit un projet hôte, soit un projet de service :

  • Un projet hôte contient un ou plusieurs réseaux VPC partagés. L'administrateur du VPC partagé doit d'abord activer le projet en tant que projet hôte. Il peut ensuite associer un ou plusieurs projets de service à ce VPC partagé.

  • Un projet de service est un projet qui a été associé à un projet hôte par un administrateur du VPC partagé. Cette opération d'association lui permet de participer au VPC partagé. Il est courant d'avoir plusieurs projets de service gérés et administrés par différents départements ou équipes de votre entreprise.

  • Un projet ne peut pas être à la fois un projet hôte et un projet de service. Ainsi, un projet de service ne peut pas jouer à son tour le rôle de projet hôte pour des projets de service.

  • Vous pouvez créer et utiliser plusieurs projets hôtes. Cependant, chaque projet de service ne peut être associé qu'à un seul projet hôte. Voir la section Projets hôtes multiples pour un exemple de ce cas de figure.

Par souci de clarté, un projet qui ne participe pas au VPC partagé est appelé projet autonome. Ce terme souligne qu'il ne s'agit ni d'un projet hôte, ni d'un projet de service.

Réseaux

Un réseau VPC partagé est un réseau VPC défini au sein d'un projet hôte et mis à disposition en tant que réseau partagé de manière centralisée pour les ressources éligibles présentes dans les projets de service. Les réseaux VPC partagés peuvent être en mode automatique ou personnalisé, mais les réseaux anciens ne sont pas compatibles.

Lorsqu'un projet hôte est activé, tous ses réseaux VPC existants deviennent des réseaux VPC partagés, et tout réseau créé dans ce projet deviendra lui aussi automatiquement un réseau VPC partagé. De ce fait, un même projet hôte peut comprendre plusieurs réseaux VPC partagés.

Le projet hôte et les projets de service sont reliés par des associations définies au niveau du projet. Les sous-réseaux des réseaux VPC partagés du projet hôte sont accessibles par les administrateurs de projet de service comme indiqué dans la section suivante, Administrateurs et IAM.

Administrateurs et IAM

Le VPC partagé utilise les rôles de gestion des identités et des accès (IAM) pour la délégation des tâches administratives. Les rôles suivants peuvent être accordés aux différents types de membres IAM, tels que les utilisateurs, les groupes Google, les domaines Google ou les comptes de service GCP. Si vous devez contacter l'un de ces administrateurs, vous pouvez les rechercher dans la stratégie IAM de votre organisation ou de votre projet. Si vous ne disposez pas des autorisations requises, vous devez contacter un administrateur de réseau ou de projet de votre organisation.

Rôles administratifs requis

Administrateur Raison
Administrateur d'organisation
  • Membre IAM de l'organisation
Les administrateurs d'organisation disposent du rôle resourcemanager.organizationAdmin pour votre organisation. Ils désignent les administrateurs de VPC partagé en leur accordant les rôles de création et de suppression de projet appropriés, ainsi que le rôle Administrateur de VPC partagé pour l'organisation. Ces administrateurs peuvent définir des stratégies au niveau de l'organisation, mais certaines actions relatives aux dossiers et aux projets nécessitent des rôles supplémentaires vis-à-vis des dossiers et des projets.
Administrateur de VPC partagé
  • membre IAM de l'organisation, ou
  • membre IAM d'un dossier (bêta)
Les administrateurs de VPC partagé possèdent le rôle d'Administrateur de VPC partagé (compute.xpnAdmin) au niveau de l'organisation ou d'un ou plusieurs dossiers. Ils effectuent diverses tâches nécessaires à la configuration du VPC partagé, comme l'activation de projets hôtes, l'association de projets de service à des projets hôtes et la délégation de l'accès à tout ou partie des sous-réseaux des réseaux VPC partagés. En règle générale, l'administrateur de VPC partagé pour un projet hôte donné est également le propriétaire de ce projet.
Un utilisateur qui se voit attribuer le rôle d'administrateur de VPC partagé au niveau de l'organisation possède ce rôle pour tous les dossiers de l'organisation. Un utilisateur qui se voit attribuer ce rôle au niveau d'un dossier possède le rôle au niveau de ce dossier, et pour tous les dossiers imbriqués qu'il contient. Un administrateur de VPC partagé peut lier des projets dans deux dossiers différents uniquement s'il possède le rôle pour ces deux dossiers.
Administrateur de projet de service
  • Membre IAM d'un projet de service, ou
  • Membre IAM de l'organisation
L'administrateur de VPC partagé définit l'administrateur de projet de service en accordant à un membre IAM le rôle d'Utilisateur de réseau (compute.networkUser), soit pour le projet hôte tout entier, soit pour certains sous-réseaux de ses réseaux VPC partagés. Les administrateurs de projet de service assument également la propriété et le contrôle des ressources définies dans les projets de service. Ils doivent donc avoir le rôle d'Administrateur d'instances (compute.instanceAdmin) pour les projets de service correspondants. Ils peuvent également détenir des rôles IAM supplémentaires pour les projets de service, tels que le rôle de propriétaire du projet.

Administrateurs de projet de service

Lors de la définition de chaque administrateur de projet de service, un administrateur de VPC partagé peut autoriser l'utilisation du projet hôte tout entier ou de certains sous-réseaux seulement :

  • Autorisations au niveau du projet : l'administrateur de projet de service peut être autorisé à utiliser tous les sous-réseaux du projet hôte si l'administrateur du VPC partagé lui attribue le rôle compute.networkUser pour le projet hôte tout entier. Cet administrateur de projet de service est alors autorisé à utiliser tous les sous-réseaux de tous les réseaux VPC du projet hôte, y compris les sous-réseaux et les réseaux VPC ajoutés ultérieurement au projet hôte.

  • Autorisations au niveau du sous-réseau : l'administrateur de projet de service peut également se voir accorder un ensemble d'autorisations limitées à certains sous-réseaux si l'administrateur du VPC partagé lui attribue le rôle compute.networkUser pour les sous-réseaux concernés. Un administrateur de projet de service détenant des autorisations au niveau d'un ou plusieurs sous-réseaux ne peut utiliser que ces sous-réseaux. Lorsque de nouveaux réseaux VPC partagés ou de nouveaux sous-réseaux sont ajoutés au projet hôte, un administrateur de VPC partagé doit examiner les liaisons d'autorisation définies pour le rôle compute.networkUser afin de s'assurer que les autorisations au niveau du sous-réseau attribuées à tous les administrateurs de projets de service correspondent à la configuration souhaitée.

Administrateurs de réseaux et de sécurité

Les administrateurs de VPC partagé ont un contrôle total sur les ressources du projet hôte, ce qui comprend l'administration du réseau VPC partagé. Ils peuvent éventuellement déléguer certaines tâches d'administration de réseau à d'autres membres IAM :

Administrateur Raison
Administrateur de réseaux
  • Membre IAM du projet hôte, ou
  • Membre IAM de l'organisation
L'administrateur du VPC partagé définit un administrateur de réseaux en accordant à un membre IAM le rôle d'Administrateur de réseaux (compute.networkAdmin) pour le projet hôte. Les administrateurs réseau ont un contrôle total sur toutes les ressources réseau, à l'exception des règles de pare-feu et des certificats SSL.
Administrateur de sécurité
  • Membre IAM du projet hôte, ou
  • Membre IAM de l'organisation
L'administrateur du VPC partagé peut définir un administrateur de sécurité en accordant à un membre IAM le rôle d'Administrateur de sécurité (compute.securityAdmin) pour le projet hôte. Les administrateurs de sécurité gèrent les règles de pare-feu et les certificats SSL.

Caractéristiques

Quotas et limites

Les projets hôtes de VPC partagé sont soumis aux quotas VPC par projet standard. Les réseaux VPC partagés sont soumis aux limites par réseau et aux limites par instance propres aux réseaux VPC. En outre, les relations entre projets hôtes et projets de service sont régies par des limites propres aux VPC partagés.

Facturation

La facturation d'une ressource participant à un réseau VPC partagé est attribuée au projet de service dans lequel se trouve cette ressource, même si celle-ci utilise le réseau VPC partagé du projet hôte.

  • Les tarifs et règles utilisés pour calculer les montants à facturer pour les ressources des projets de service utilisant un réseau VPC partagé sont les mêmes que si les ressources étaient situées dans le projet hôte.
  • La facturation du trafic de sortie généré par une ressource est attribuée au projet dans lequel cette ressource est définie :
    • Le trafic de sortie d'une instance est attribué au projet contenant cette instance. Par exemple, si une instance est créée dans un projet de service, mais utilise un réseau VPC partagé, toute facturation du trafic de sortie qu'elle génère est attribuée à son projet de service. Cela vous permet d'utiliser des VPC partagés pour structurer les ressources en centres de coûts pour votre organisation.
    • Les coûts associés à un équilibreur de charge sont imputés au projet contenant les composants de cet équilibreur de charge. Pour plus d'informations sur l'équilibrage de charge et les VPC partagés, reportez-vous à la section Équilibrage de charge.
    • Le trafic de sortie vers les VPN est attribué au projet contenant la ressource de passerelle VPN. Par exemple, si une passerelle VPN est créée dans le réseau VPC partagé, elle est contenue dans le projet hôte. Quel que soit le projet de service qui l'a généré, le trafic de sortie empruntant la passerelle VPN est attribué au projet hôte.

Resources

Ressources éligibles

Les ressources de projets de service suivantes peuvent participer au VPC partagé sous réserve de certaines limitations pratiques :

Limites pratiques applicables aux ressources éligibles

Les limitations suivantes s'appliquent aux ressources éligibles à la participation à un scénario VPC partagé :

  • L'utilisation d'un réseau VPC partagé n'est pas obligatoire. Par exemple, les administrateurs d'instances peuvent créer des instances dans le projet de service utilisant un réseau VPC de ce projet. Les réseaux définis dans les projets de service ne sont pas partagés.

  • Certaines ressources doivent être recréées pour pouvoir utiliser un réseau VPC partagé. Lorsqu'un administrateur de VPC partagé associe un projet existant à un projet hôte, le projet ainsi associé devient un projet de service, mais ses ressources existantes n'utilisent pas automatiquement les ressources réseau partagées. Pour utiliser un réseau VPC partagé, un administrateur de projet de service doit créer une ressource éligible et la configurer afin d'utiliser un sous-réseau d'un réseau VPC partagé. Par exemple, une instance existante d'un projet de service ne peut pas être reconfigurée pour l'utilisation d'un réseau VPC partagé, mais il est possible de créer une instance pour utiliser les sous-réseaux disponibles dans un réseau VPC partagé. Cette limitation s'applique aux zones privées.

Ressources non éligibles

Dans un projet de service, les ressources du type environnement flexible App Engine ne peuvent pas participer au VPC partagé.

Adresses IP

Les instances situées dans des projets de service associés à un projet hôte utilisant le même réseau VPC partagé peuvent communiquer entre elles à l'aide d'adresses IP internes éphémères ou d'adresses IP internes statiques réservées, sous réserve des règles de pare-feu applicables.

Une adresse IP interne éphémère peut être automatiquement attribuée à une instance située dans un projet de service. Par exemple, lorsque les administrateurs de projets de service créent des instances, ils sélectionnent une zone, le réseau VPC partagé et un sous-réseau disponible. L'adresse IP provient de la plage d'adresses IP disponibles dans le sous-réseau partagé sélectionné.

Un administrateur de projet de service peut également choisir de réserver une adresse IP interne statique. L'objet adresse IP proprement dit doit être créé dans le même projet de service que l'instance qui l'utilisera, même si la valeur de l'adresse IP proviendra de la plage d'adresses IP disponibles dans un sous-réseau partagé sélectionné au sein du réseau VPC partagé. Pour en savoir plus, reportez-vous à la section Réserver une adresse IP interne statique de la page Provisionner un VPC partagé.

Les adresses IP externes définies dans le projet hôte ne peuvent être utilisées que par les ressources de ce projet. Elles ne sont pas utilisables dans les projets de service. Les projets de service peuvent gérer leur propre ensemble d'adresses IP externes. Par exemple, une instance faisant partie d'un projet de service doit utiliser une adresse IP externe définie dans ce même projet de service. C'est le cas même si cette instance utilise une adresse IP interne provenant d'un réseau VPC partagé défini dans le projet hôte.

DNS interne

Les machines virtuelles d'un même projet de service peuvent communiquer entre elles au moyen des noms DNS internes créés automatiquement par GCP. Ces noms DNS utilisent l'ID du projet de service dans lequel sont créées les VM, même si les noms pointent vers des adresses IP internes dans le projet hôte. Pour obtenir une explication complète, reportez-vous à la section Noms DNS internes et VPC partagé dans la documentation relative au DNS interne.

Zones privées Cloud DNS

Vous pouvez utiliser les zones privées Cloud DNS dans le cadre d'un réseau VPC partagé. Vous devez créer votre zone privée dans le projet hôte et autoriser l'accès à la zone pour le réseau VPC partagé. De plus, vous devez activer les zones DNS privées dans chaque projet de service. Pour obtenir une explication complète, consultez la section Zones privées et VPC partagé de la Présentation de Cloud DNS.

Équilibrage de charge

Le VPC partagé peut être utilisé conjointement avec l'équilibrage de charge. Tous les composants d'équilibrage de charge doivent se trouver dans le même projet, qu'il s'agisse d'un projet hôte ou d'un projet de service. Il n'est pas possible de créer certains composants d'équilibrage de charge dans un projet hôte et de créer les autres dans un projet de service associé. Toutefois, la règle de transfert d'un équilibreur de charge interne créé dans un projet de service peut faire référence à un sous-réseau partagé du projet hôte auquel ce projet de service est associé. Pour plus d'informations, reportez-vous à la section Créer un équilibreur de charge interne de la page Provisionner un VPC partagé.

Le tableau suivant récapitule les composants pour l'équilibrage de charge HTTP(S), avec proxy SSL et avec proxy TCP. Dans la plupart des cas, vous créez les instances backend dans un projet de service. Dans ce cas, tous les composants de l'équilibreur de charge sont créés au sein de ce projet. Il est également possible de créer les instances backend dans le projet hôte. Dans ce cas, tous les composants de l'équilibreur de charge doivent figurer dans le projet hôte.

Équilibreur de charge Adresse IP Règle de transfert Autres composants frontend Composants backend
Équilibrage de charge HTTP(S) Une adresse IP externe doit être définie dans le même projet que les instances soumises à l'équilibrage de charge (le projet de service). La règle de transfert externe doit être définie dans le même projet que les instances backend (le projet de service). Le proxy HTTP cible ou le proxy HTTPS cible et le mappage d'URL associé doivent être définis dans le même projet que les instances backend. Un service de backend global doit être défini dans le même projet que les instances backend. Ces instances doivent se trouver dans des groupes d'instances associés au service de backend en tant que backends. Les vérifications de l'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.
Équilibrage de charge proxy SSL Le proxy SSL cible doit être défini dans le même projet que les instances backend.
Équilibrage de charge proxy TCP Le proxy TCP cible doit être défini dans le même projet que les instances backend.

Le tableau suivant récapitule les composants des deux types d'équilibreurs de charge régionaux. Il montre comment une règle de transfert destinée à un équilibreur de charge interne peut faire référence à un sous-réseau partagé d'un réseau VPC partagé afin de fournir un équilibrage de charge interne au sein de ce réseau VPC partagé.

Équilibreur de charge Adresse IP Règle de transfert Composants backend
Équilibrage de charge au niveau du réseau Une adresse IP externe régionale doit être définie dans le même projet que les instances soumises à l'équilibrage de charge. Une règle de transfert externe régionale doit être définie dans le même projet que les instances du pool cible (le projet de service). Le pool cible doit être défini dans le même projet et dans la même région que les instances qu'il cible. Les vérifications d'état associées au pool cible doivent également être définies dans le même projet.
Équilibrage de charge interne L'adresse IP interne peut provenir du projet hôte ou du projet de service :
  • Si l'équilibreur de charge doit être disponible sur le réseau VPC partagé, l'adresse IP interne doit provenir de la plage d'adresses IP principales de l'un des sous-réseaux partagés.
  • Si l'équilibreur de charge doit être local à un projet de service, l'adresse IP interne peut provenir d'un sous-réseau du réseau du projet de service.
Une règle de transmission interne doit être définie dans le même projet que les instances soumises à l'équilibrage de charge. Toutefois, le sous-réseau auquel elle fait référence détermine si l'équilibreur de charge fonctionne dans un scénario de VPC partagé :
  • Si l'équilibreur de charge doit être disponible sur le réseau VPC partagé, la règle de transfert doit faire référence à un sous-réseau partagé. Pour plus de précisions, reportez-vous à la section Créer un équilibreur de charge interne de la page Provisionner un VPC partagé.
  • Si l'équilibreur de charge doit être local à l'un des projets de service, la règle de transfert fait référence à un sous-réseau d'un réseau de ce projet de service.
Un service de backend régional doit être défini dans le même projet que les instances à équilibrage de charge. Les instances à équilibrage de charge doivent se trouver dans des groupes d'instances associés au service de backend en tant que backends. Les vérifications de l'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.

Exemples et cas d'utilisation

Concepts fondamentaux

L'exemple suivant présente un scénario de VPC partagé simple :

Concepts de base (cliquez pour agrandir)
Concepts de base (cliquez pour agrandir)
  • Un administrateur de VPC partagé de l'organisation a créé un projet hôte et lui a associé deux projets de service :

    • Les administrateurs de projet de service définis dans Service Project A peuvent être configurés pour accéder à tout ou partie des sous-réseaux du réseau VPC partagé. Un administrateur de projet de service disposant au minimum d'autorisations de niveau sous-réseau sur le sous-réseau 10.0.1.0/24 Subnet a créé l'instance Instance A dans une zone de la région us-west1. Cette instance reçoit son adresse IP interne 10.0.1.3 du bloc CIDR 10.0.1.0/24.

    • Les administrateurs de projet de service définis dans Service Project B peuvent être configurés pour accéder à tout ou partie des sous-réseaux du réseau VPC partagé. Un administrateur de projet de service disposant au minimum d'autorisations de niveau sous-réseau sur le sous-réseau 10.15.2.0/24 Subnet a créé l'instance Instance B dans une zone de la région us-east1. Cette instance reçoit son adresse IP interne 10.15.2.4 du bloc CIDR 10.15.2.0/24.

  • Le projet autonome ne participe aucunement au VPC partagé, dans la mesure où il ne s'agit ni d'un projet hôte, ni d'un projet de service. Les instances autonomes sont créées par les membres IAM disposant au minimum du rôle compute.InstanceAdmin pour le projet.

Projets hôtes multiples

L'exemple suivant montre comment utiliser les réseaux VPC partagés pour créer des environnements de test et de production distincts. Dans ce scénario, une organisation a décidé d'utiliser deux projets hôtes distincts : un environnement de test et un environnement de production.

Projets hôtes multiples (cliquez pour agrandir)
Projets hôtes multiples (cliquez pour agrandir)
  • Un administrateur de VPC partagé de l'organisation a créé deux projets hôtes et leur a associé deux projets de service, comme suit :

    • Les projets de service Apps Testing et Mobile Testing sont associés au projet hôte Test Environment. Les administrateurs de projet de service définis de part et d'autre peuvent être configurés pour accéder à tout ou partie des sous-réseaux du réseau Testing Network.

    • Les projets de service Apps Production et Mobile Production sont associés au projet hôte Production Environment. Les administrateurs de projet de service définis de part et d'autre peuvent être configurés pour accéder à tout ou partie des sous-réseaux du réseau Production Network.

  • Les deux projets hôtes disposent d'un réseau VPC partagé comportant des sous-réseaux configurés pour utiliser les mêmes plages CIDR. Dans le réseau Testing Network comme dans le réseau Production Network, les deux sous-réseaux sont les suivants :

    • Sous-réseau 10.0.1.0/24 Subnet dans la région us-west1

    • Sous-réseau 10.15.2.0/24 Subnet dans la région us-east1

  • Considérons l'instance Instance AT dans le projet de service Apps Testing et l'instance Instance AP dans le projet de service Apps Production :

    • Les administrateurs de projet de service peuvent créer des instances comme celles-ci à condition de disposer au minimum d'autorisations de niveau sous-réseau sur le sous-réseau 10.0.1.0/24 Subnet.

    • Notez que les deux instances utilisent l'adresse IP 10.0.1.3. Cela est acceptable dans la mesure où chaque instance se trouve dans un projet de service associé à un même projet hôte contenant son propre réseau VPC partagé. Les réseaux de test et de production ont été intentionnellement configurés de la même manière.

    • Les instances utilisant le sous-réseau 10.0.1.0/24 Subnet doivent se trouver dans une zone de la même région que le sous-réseau, même si ce sous-réseau et ces instances sont définis dans des projets distincts. Étant donné que le sous-réseau 10.0.1.0/24 Subnet est situé dans la région us-west1, les administrateurs de projet de service qui créent des instances à l'aide de ce sous-réseau doivent choisir une zone de la même région, telle que us-west1-a.

Scénario de cloud hybride

L'exemple suivant montre comment le VPC partagé peut être utilisé dans un environnement hybride.

Cloud hybride (cliquez pour agrandir)
Cloud hybride (cliquez pour agrandir)

Dans cet exemple, une organisation a créé un projet hôte unique comportant un seul réseau VPC partagé. Ce réseau VPC partagé est connecté via Cloud VPN à un réseau sur site. Certains services et applications sont hébergés dans GCP, tandis que d'autres sont maintenus sur site :

  • Un administrateur de VPC partagé a activé le projet hôte et lui a connecté trois projets de service : Service Project A, Service Project B et Service Project C.

    • Chacun de ces projets de service peut être géré par une équipe distincte. Les autorisations IAM ont été configurées de telle sorte que l'administrateur de projet de service défini pour un projet de service donné ne dispose d'aucune autorisation au niveau des autres projets de service.

    • L'administrateur de VPC partagé a accordé des autorisations au niveau du sous-réseau ou du projet aux seuls administrateurs de projet de service requis pour créer des instances utilisant le réseau VPC partagé :

      • Un administrateur du projet de service Service Project A dispose d'autorisations au niveau du sous-réseau 10.0.1.0/24 Subnet et peut y créer l'instance Instance A. Cet administrateur de projet de service doit choisir une zone dans la région us-west1 pour créer l'instance, car c'est la région qui contient le sous-réseau 10.0.1.0/24 Subnet. L'instance Instance A reçoit son adresse IP 10.0.1.3 de la plage d'adresses IP disponibles du sous-réseau 10.0.1.0/24 Subnet.

      • L'administrateur du projet de service Service Project B dispose d'autorisations au niveau du sous-réseau 10.15.2.0/24 Subnet et peut y créer l'instance Instance B. Cet administrateur de projet de service doit choisir une zone dans la région us-east1 pour créer l'instance, car c'est la région qui contient le sous-réseau 10.15.2.0/24 Subnet. L'instance Instance B reçoit son adresse IP 10.15.2.4 de la plage d'adresses IP disponibles du sous-réseau 10.15.2.0/24 Subnet.

      • Un administrateur du projet de service Service Project C dispose d'autorisations au niveau du projet sur l'ensemble du projet hôte et peut créer des instances dans n'importe quel sous-réseau d'un réseau VPC du projet hôte. Par exemple, cet administrateur de projet de service peut créer l'instance Instance C dans le sous-réseau 10.7.1.0/24 Subnet, en choisissant une zone dans la région us-east1 pour correspondre à la région du sous-réseau. L'instance Instance C reçoit son adresse IP 10.7.1.50 de la plage d'adresses IP disponibles du sous-réseau 10.7.1.0/24 Subnet.

    • Chaque projet de service fait l'objet d'une facturation distincte.

    • Les administrateurs de projet de service de chaque projet ont la responsabilité de créer et gérer les ressources.

  • Un administrateur de VPC partagé a délégué des tâches d'administration réseau à d'autres membres IAM, définis comme administrateurs de réseaux et de sécurité pour le réseau VPC partagé.

    • Un administrateur de réseaux a créé une passerelle Cloud VPN et configuré un tunnel VPN via Internet vers une passerelle sur site. Cette passerelle Cloud VPN peut échanger des routes avec son homologue sur site et en recevoir, car un routeur Cloud correspondant se trouvant lui aussi dans la région us-east1 a été configuré.

    • Si le mode de routage dynamique du VPC est défini sur "Mondial", le routeur Cloud applique les routes apprises vers le réseau sur site à tous les sous-réseaux du réseau VPC, et partage les routes à destination de tous les sous-réseaux VPC avec son homologue sur site.

    • Les administrateurs de sécurité créent et gèrent des règles de pare-feu dans le réseau VPC partagé afin de contrôler le trafic entre les instances de GCP et le réseau sur site.

    • Sous réserve des règles de pare-feu applicables, les instances appartenant aux projets de service peuvent être configurées pour communiquer avec les services internes, tels que les serveurs de base de données ou de répertoire situés sur site.

Service Web à deux niveaux

L'exemple suivant montre comment le VPC partagé peut être utilisé pour déléguer des responsabilités administratives et mettre en œuvre le principe du moindre privilège. Dans ce scénario, une organisation dispose d'un service Web structuré en deux niveaux gérés par des équipes distinctes. Le niveau 1 représente le composant externe, déployé derrière un équilibreur de charge HTTP global. Le niveau 2 représente le service interne sur lequel repose le niveau 1, et il est équilibré à l'aide d'un équilibreur de charge interne.

Service Web à deux niveaux (cliquez pour agrandir)
Service Web à deux niveaux (cliquez pour agrandir)

Le VPC partagé vous permet de mapper chaque niveau du service Web sur un projet distinct, afin que ces niveaux puissent être gérés par des équipes différentes tout en partageant un réseau VPC commun :

  • Les ressources associées à chaque niveau, telles que les instances et les composants d'équilibrage de charge, sont placées dans des projets de service individuels gérés chacun par une équipe distincte.

  • Le projet de service correspondant à chaque niveau a été associé au projet hôte par un administrateur de VPC partagé. L'Administrateur de VPC partagé a également activé le projet hôte.

    • Des équipes distinctes peuvent gérer chaque niveau du service Web en leur qualité d'administrateurs du projet de service approprié.

    • Chaque projet de service fait l'objet d'une facturation distincte.

    • Les administrateurs de projet de service de chaque projet ont la responsabilité de créer et gérer les ressources.

  • Le contrôle des accès au réseau s'établit comme suit :

    • Les membres IAM qui travaillent uniquement sur le niveau 1 sont des administrateurs du projet de service Tier 1 Service Project et disposent d'autorisations au niveau du sous-réseau pour le seul sous-réseau 10.0.1.0/24 Subnet. Dans cet exemple, un tel administrateur de projet de service a créé trois instances Tier 1 Instances au sein de ce sous-réseau.

    • Les membres IAM qui travaillent uniquement sur le niveau 2 sont des administrateurs du projet de service Tier 2 Service Project et se voient accorder des autorisations au niveau du sous-réseau pour le seul sous-réseau 10.0.2.0/24 Subnet. Dans cet exemple, un autre administrateur de projet de service a créé trois instances Tier 2 Instances dans ce sous-réseau, ainsi qu'un équilibreur de charge interne dont la règle de transfert utilise une adresse IP de la plage disponible dans ce sous-réseau.

    • Les membres IAM qui supervisent l'ensemble du service Web sont définis comme administrateurs de projet de service dans les deux projets de service, et disposent d'autorisations au niveau du projet hôte qui leur permettent d'utiliser n'importe quel sous-réseau défini dans ce dernier.

    • Au besoin, un administrateur de VPC partagé peut déléguer des tâches d'administration réseau à des administrateurs de réseaux et de sécurité.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…