Hub administration overview

This page provides an overview of the Network Connectivity Center hub administrator role (roles/networkconnectivity.hubAdmin). An Identity and Access Management (IAM) principal who has the hub administrator role can do the following:

Custom roles can also be used if they at least include the same permissions of the Network Connectivity Center hub administrator role.

How VPC spokes join a hub

If a VPC network and a Network Connectivity Center hub are located in the same project, creating a VPC spoke for the VPC network immediately establishes connectivity to the hub without any additional steps.

If a VPC network and a Network Connectivity Center hub are located in different projects, the process for creating a VPC spoke is as follows:

  1. A hub administrator establishes IAM policy bindings that let spoke administrators in other projects create VPC spoke proposals. Note: Hub administrators can change IAM policy bindings at any time. For example, a hub administrator might revoke access later, preventing a spoke administrator from creating additional spoke proposals. This is true when auto accept for spokes is not enabled.
  2. During hub creation, the hub administrator chooses the connectivity topology between the default mesh topology and star topology.
  3. A spoke administrator proposes a VPC spoke. If the spoke proposal is for a hub that is configured to use the star topology, the spoke administrator assigns the spoke to either the center or the edge group. For mesh topology, all spokes belong to the single default group.
  4. A hub administrator reviews each spoke proposal, and then accepts or rejects the proposal. The following describes how hub connectivity works following accepting or rejecting a proposal:
    • A spoke becomes active only after a hub administrator accepts the spoke proposal. Network Connectivity Center only provides network connectivity to active spokes.
    • A hub administrator can reject a previously accepted VPC spoke, making the spoke inactive. When a previously active VPC spoke becomes inactive, Network Connectivity Center does not provide network connectivity to the spoke.

Auto-accept projects

A hub administrator can enable auto-accept for spoke groups in a hub. When enabled, spokes from the auto-accept projects list are automatically accepted into the hub and the group without the need for review and become active immediately after the spoke proposal.

The hub route table

The hub route table shows subnet routes imported from the VPC spokes. When a new VPC spoke is created, all local subnet routes from the VPC network are exported to the hub unless the spoke administrator uses the exclude-export-ranges flag in the Google Cloud CLI or the excludeExportRanges field in the API. For more information, see subnet route uniqueness.

When you create a new VPC spoke, the following occurs:

  • A spoke belongs to exactly one group.
  • Each group has a corresponding route table.
  • Spokes are associated with that route table.
  • Spoke subnets are propagated to one or more route tables.

Because there is only one default group in a mesh topology connectivity, the subnet routes are propagated to a single hub route table. Spokes connected to a hub that supports star topology belong to one of two different groups, namely, center and edge. So, two hub route tables are generated, one associated with each spoke group. Spokes in the center group have their subnet routes propagated to the center and edge route tables. Spokes in the edge group have their subnet routes propagated to the center route table.

For detailed information about connectivity topologies, see Preset topologies.

Google Cloud automatically updates the VPC network route table of each VPC spoke and the Network Connectivity Center hub route table when any of the following occur:

For more information, see Route tables that show subnet routes and Routes in the VPC documentation.

What's next