Présentation de l'administration de Hub

Cette page propose une présentation du rôle d'administrateur de Hub Network Connectivity Center (roles/networkconnectivity.hubAdmin). Un compte principal IAM (Identity and Access Management) disposant du rôle d'administrateur de Hub peut effectuer les opérations suivantes :

Vous pouvez également utiliser des rôles personnalisés s'ils incluent au moins les mêmes autorisations que le rôle d'administrateur de Hub Network Connectivity Center.

Comment les spokes VPC rejoignent un hub

Si un réseau VPC et un hub Network Connectivity Center se trouvent dans le même projet, la création d'un spoke VPC pour le réseau VPC établit immédiatement une connectivité au hub sans étape supplémentaire.

Si un réseau VPC et un hub Network Connectivity Center se trouvent dans des projets différents, le processus de création d'un spoke VPC est le suivant :

  1. Un administrateur de hub établit des liaisons de stratégie IAM qui permettent aux administrateurs spoke d'autres projets de créer des propositions de spoke de VPC. Remarque : Les administrateurs de hub peuvent modifier les liaisons de stratégie IAM à tout moment. Par exemple, un administrateur de hub peut révoquer l'accès ultérieurement, ce qui empêche un administrateur satellite de créer des propositions satellites supplémentaires. C'est le cas lorsque l'acceptation automatique des spokes n'est pas activée.
  2. Lors de la création du hub, son administrateur choisit la topologie de connectivité entre la topologie de maillage par défaut et la topologie en étoile (preview).
  3. Un administrateur spoke propose un spoke VPC. Si la proposition de spoke concerne un hub configuré pour utiliser la topologie en étoile (preview), l'administrateur spoke l'attribue au groupe central ou au groupe périphérique. Dans la topologie de maillage, tous les spokes appartiennent à un seul et même groupe, celui par défaut.
  4. Un administrateur de hub examine chaque proposition de spoke, puis accepte ou refuse la proposition. La section suivante décrit le fonctionnement de la connectivité hub dans le cadre de l'acceptation ou du refus d'une proposition :
    • Un spoke ne devient actif qu'une fois qu'un administrateur de hub a accepté la proposition de spoke. Le centre de connectivité réseau ne fournit une connectivité réseau qu'aux spokes actifs.
    • Un administrateur de hub peut rejeter un spoke VPC précédemment accepté, ce qui rend le spoke inactif. Lorsqu'un spoke VPC précédemment actif devient inactif, Network Connectivity Center ne fournit pas de connectivité réseau au spoke.

Accepter automatiquement les projets

Un administrateur de hub peut activer l'acceptation automatique des groupes de spokes dans un hub. Lorsque cette option est activée, les spokes issus de la liste des projets avec acceptation automatique sont automatiquement acceptés dans le hub et dans le groupe, sans nécessiter d'examen, et deviennent actifs immédiatement après la proposition de spoke.

La table de routage du hub

La table de routage du hub affiche les routes de sous-réseau importées à partir des spokes VPC. Lorsqu'un spoke VPC est créé, toutes les routes de sous-réseau locales du réseau VPC sont exportées vers le hub, sauf si l'administrateur spoke utilise l'option exclude-export-ranges dans la Google Cloud CLI ou dans le champ excludeExportRanges de l'API. Pour plus d'informations, consultez la section Unicité des routes de sous-réseau.

Voici ce qui se produit lorsque vous créez un spoke VPC :

  • Un spoke appartient à un seul groupe.
  • Chaque groupe possède une table de routage correspondante.
  • Les spokes sont associés à cette table de routage.
  • Les sous-réseaux spoke sont propagés vers une ou plusieurs tables de routage.

Étant donné qu'il n'y a qu'un seul groupe par défaut dans une connectivité de topologie de maillage, les routes de sous-réseau sont propagées vers une seule table de routage de hub. Les spokes connectés à un hub compatible avec la topologie en étoile (preview) appartiennent à l'un des deux groupes suivants : le groupe central ou le groupe périphérique. Ainsi, deux tables de routage de hub sont générées, chacune associée à un groupe de spoke. Les routes de sous-réseau des spokes du groupe central sont propagées vers les tables de routage du groupe central et du groupe périphérique. Les routes de sous-réseau des spokes du groupe périphérique sont propagées vers la table de routage du groupe central.

Pour en savoir plus sur les topologies de connectivité, consultez la page Topologies prédéfinies.

Google Cloud met automatiquement à jour la table de routage du réseau VPC de chaque spoke VPC et la table de routage du hub Network Connectivity Center lorsque l'un des événements suivants se produit :

Pour plus d'informations, consultez les sections Tables de routage indiquant les routes de sous-réseau et Routes dans la documentation sur les VPC.

Étapes suivantes