VPC partagé

Cette page présente le VPC partagé dans Google Cloud. Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau cloud privé virtuel (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 et 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.

Remarque : Le VPC partagé est également appelé "XPN" dans l'API.

Concepts

Organisations, dossiers et projets

Un VPC partagé connecte les projets définis au sein d'une même organisation. Des projets associé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 concernant la hiérarchie des ressources Google Cloud.

Le projet hôte et les projets de service participant à un VPC partagé ne peuvent pas appartenir à des organisations distinctes. La seule exception concerne la migration de vos projets d'une organisation à une autre. Pendant la migration, les projets de service peuvent se trouver temporairement dans une organisation différente de celle du projet hôte. Pour en savoir plus sur la migration de projets, consultez la section Migrer des projets.

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. Un administrateur de VPC partagé doit d'abord activer un 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.

• Vous pouvez créer des réseaux, des sous-réseaux, des plages d'adresses secondaires, des règles de pare-feu et d'autres ressources réseau dans le projet hôte. Le projet hôte peut ensuite partager les sous-réseaux sélectionnés, y compris les plages secondaires, avec les projets de service. Les services exécutés dans un projet de service peuvent utiliser un VPC partagé pour communiquer avec les ressources exécutées dans les autres projets de service.

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.

Un réseau VPC autonome est un réseau VPC non partagé qui existe dans un projet autonome ou 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 anciens réseaux ne sont pas compatibles.

Lorsqu'un projet hôte est activé, deux options de partage des réseaux sont disponibles :

• Vous pouvez partager tous les sous-réseaux de projet hôte. Si vous sélectionnez cette option, tous les nouveaux sous-réseaux créés dans le projet hôte, y compris les sous-réseaux des nouveaux réseaux, seront également partagés.
• Vous pouvez spécifier des sous-réseaux individuels à partager. Si vous partagez des sous-réseaux individuellement, seuls ces sous-réseaux sont partagés, sauf si vous modifiez manuellement la liste.

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.

Contraintes liées aux règles d'administration

Les règles d'administration et les autorisations IAM fonctionnent ensemble pour fournir différents niveaux de contrôle d'accès. Les règles d'administration vous permettent de définir des contrôles au niveau de l'organisation, d'un dossier ou d'un projet.

Si vous êtes administrateur des règles d'administration, vous pouvez spécifier les contraintes liées au VPC partagé suivantes dans une règle d'administration :

• Vous pouvez restreindre l'ensemble de projets hôtes auxquels un projet non hôte ou des projets non hôtes d'un dossier ou d'une organisation peuvent être associés. La contrainte s'applique lorsqu'un administrateur de VPC partagé associe un projet de service à un projet hôte. La contrainte n'affecte pas les rattachements existants. Les rattachements existants restent intacts même si une règle en refuse de nouveaux. Pour en savoir plus, consultez la contrainte constraints/compute.restrictSharedVpcHostProject.

• Vous pouvez spécifier les sous-réseaux VPC partagés auxquels un projet de service a accès au niveau du projet, du dossier ou de l'organisation. La contrainte s'applique lorsque vous créez des ressources dans les sous-réseaux spécifiés et n'affecte pas les ressources existantes. Les ressources existantes continuent de fonctionner normalement dans leurs sous-réseaux, même lorsqu'une règle empêche l'ajout de nouvelles ressources. Pour en savoir plus, consultez la contrainte constraints/compute.restrictSharedVpcSubnetworks.

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 comptes principaux 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 (rôle IAM)	Objectif
Administrateur de l'organisation (resourcemanager.organizationAdmin)   • Compte principal 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é (compute.xpnAdmin et resourcemanager.projectIamAdmin) • Compte principal IAM de l'organisation, ou • Compte principal IAM d'un dossier	Les administrateurs de VPC partagé possèdent les rôles Administrateur de VPC Compute partagé (compute.xpnAdmin) et Administrateur IAM de projet (resourcemanager.projectIamAdmin) pour l'organisation ou pour 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 Compute 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 (compute.networkUser)   • Compte principal IAM de l'organisation, ou   • Compte principal IAM du projet hôte, ou   • Compte principal IAM dans certains sous-réseaux du projet hôte	L'administrateur de VPC partagé définit l'administrateur de projet de service en accordant à un compte principal IAM le rôle 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 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 : un administrateur de projet de service peut être autorisé à utiliser tous les sous-réseaux du projet hôte si l'administrateur de 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 : un 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 projet 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 comptes principaux IAM :

Administrateur	Objectif
Administrateur réseau   • Compte principal IAM du projet hôte, ou   • Compte principal IAM de l'organisation	L'administrateur de VPC partagé définit un administrateur réseau en accordant à un compte principal IAM le rôle Administrateur réseau (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é   • Compte principal IAM du projet hôte, ou   • Compte principal IAM de l'organisation	L'administrateur de VPC partagé peut définir un administrateur de sécurité en accordant à un compte principal IAM le rôle 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.

Spécifications

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 sortant empruntant la passerelle VPN est attribué au projet hôte.
  • Les coûts liés au trafic provenant d'une ressource d'un projet de service VPC partagé qui est transféré via un rattachement de VLAN sont attribués au projet propriétaire du rattachement de VLAN. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.

Ressources

Ressources éligibles

Vous pouvez utiliser la plupart des produits et fonctionnalités Google Cloud dans les projets de service VPC partagé.

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.

Adresses IP

Lorsque vous créez une instance dans un projet de service, vous pouvez la configurer en tant qu'instance à pile simple (IPv4 uniquement) ou à double pile (IPv4 et IPv6), selon la configuration du sous-réseau du projet hôte. Pour en savoir plus, consultez la page Créer une instance.

Les instances situées dans des projets de service associés à un projet hôte qui utilise le même réseau VPC partagé peuvent communiquer entre elles à l'aide de leurs adresses IPv4 internes, ou de leurs adresses IPv6 internes ou externes, en fonction des règles de pare-feu applicables.

Les administrateurs de projet de service peuvent attribuer l'un des types d'adresses IP suivants aux ressources d'un projet de service :

• Adresses IPv4 et IPv6 éphémères : une adresse IP éphémère peut être automatiquement attribuée à une instance située dans un projet de service. Par exemple, lorsque les administrateurs de projet de service créent des instances, ils sélectionnent le réseau VPC partagé ainsi qu'un sous-réseau partagé disponible. L'adresse IPv4 interne principale de l'instance provient de la plage d'adresses IP disponibles dans la plage d'adresses IPv4 principale du sous-réseau partagé sélectionné. Si l'instance est configurée avec deux piles, l'adresse IPv6 de l'instance provient de la plage d'adresses IP disponibles dans la plage de sous-réseau IPv6 sélectionnée du sous-réseau partagé.

  Les adresses IPv4 éphémères peuvent également être automatiquement attribuées aux équilibreurs de charge internes. Pour plus d'informations, consultez la section Créer un équilibreur de charge réseau interne à stratégie directe ou Créer un équilibreur de charge d'application interne.

• Adresses IPv4 et IPv6 internes statiques : une adresse IPv4 ou IPv6 interne statique peut être réservée dans un projet de service. L'objet de l'adresse IPv4 ou IPv6 interne doit être créé dans le même projet de service que la ressource qui l'utilise, même si la valeur de l'adresse IP provient des adresses IP disponibles du sous-réseau partagé sélectionné dans un réseau VPC partagé. Pour en savoir plus, consultez la section Réserver des adresses IPv4 et IPv6 internes statiques sur la page "Provisionner un VPC partagé".

• Adresses IPv4 externes statiques : les objets d'adresses IPv4 externes définis dans le projet hôte peuvent être utilisés par les ressources soit dans ce projet hôte, soit dans n'importe quel projet de service associé. Les projets de service peuvent également utiliser leurs propres objets d'adresses IPv4 externes. Par exemple, une instance faisant partie d'un projet de service peut utiliser une adresse IPv4 externe régionale définie dans son projet de service ou dans le projet hôte.

• Adresses IPv6 externes statiques : un administrateur de projet de service peut également choisir de réserver une adresse IPv6 externe statique. L'object de l'adresse IPv6 interne doit être créée dans le même projet de service que la ressource qui l'utilise, même si la valeur de l'adresse IP provient des adresses IPv6 disponibles du sous-réseau partagé d'un réseau VPC partagé. Pour plus d'informations, consultez la section Réserver une adresse IPv6 externe statique de la page Provisionner un VPC partagé.

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 Google Cloud. 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 sur le 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 pouvez créer votre zone privée dans le projet hôte et autoriser l'accès à la zone pour le réseau VPC partagé, ou la configurer dans un projet de service à l'aide de la liaison inter-projets.

Équilibrage de charge

Le VPC partagé peut être utilisé conjointement avec Cloud Load Balancing. 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. Bien qu'il soit possible de créer des instances backend dans le projet hôte, cette configuration n'est pas adaptée aux déploiements de VPC partagé classiques, car elle ne distingue pas les responsabilités des administrateurs réseau et des développeurs de services.

Utilisez les liens du tableau suivant pour en savoir plus sur les architectures de VPC partagé compatibles pour chaque type d'équilibreur de charge.

Type d'équilibreur de charge	Liens
Équilibreur de charge d'application externe	Architecture du VPC partagé
Équilibreur de charge d'application interne	Architecture du VPC partagé
Équilibreur de charge réseau proxy externe	Architecture du VPC partagé
Équilibreur de charge réseau proxy interne	Architecture du VPC partagé
Équilibreur de charge réseau interne à stratégie directe	Architecture du VPC partagé
Équilibreur de charge réseau externe à stratégie directe	Architecture du VPC partagé

Exemples et cas d'utilisation

Concepts fondamentaux

La figure 1 illustre un scénario de VPC partagé simple :

Figure 1 : Un projet hôte comportant un réseau VPC partagé fournit une connectivité interne pour deux projets de service, tandis qu'un projet autonome n'utilise pas le VPC partagé (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 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 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 comptes principaux IAM disposant au minimum du rôle compute.InstanceAdmin pour le projet.

Projets hôtes multiples

La figure 2 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.

Figure 2. Un projet hôte d'environnement de test et un projet hôte d'environnement de production utilisent un VPC partagé pour créer des environnements de production et de test distincts (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 dans chaque projet 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 de chaque projet 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 :

  • Le sous-réseau 10.0.1.0/24 subnet dans la région us-west1

  • Le 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

La figure 3 montre comment le VPC partagé peut être utilisé dans un environnement hybride.

Figure 3. Un réseau VPC partagé est connecté à un réseau sur site et à trois projets de service (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 Google Cloud, 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 il s'agit de 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.

    • Un 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 il s'agit de 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 comptes principaux 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 de celle-ci, car un routeur Cloud Router 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 Google Cloud 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

La figure 4 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(S). Le niveau 2 représente le service interne sur lequel repose le niveau 1. Il est équilibré à l'aide d'un équilibreur de charge TCP/UDP interne.

Figure 4. Dans ce service Web à deux niveaux, un composant externe et un service interne sont connectés à un réseau VPC partagé commun et gérés par différentes équipes (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 comptes principaux IAM qui travaillent uniquement sur le niveau 1 sont des administrateurs du projet de service Tier 1 service project et se voient accorder des 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 comptes principaux 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 comptes principaux 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

• Pour savoir comment configurer un VPC partagé, consultez la page Provisionner le VPC partagé.
• Pour apprendre à configurer des clusters Kubernetes Engine avec un VPC partagé, consultez la page Configurer des clusters avec un VPC partagé.
• Pour découvrir comment supprimer une configuration de VPC partagé, consultez la page Désactiver un VPC partagé.