최소한 Network Connectivity Center 허브 관리자 역할과 동일한 권한이 포함된 경우에는 커스텀 역할도 사용할 수 있습니다.
VPC 스포크가 허브에 조인되는 방식
VPC 네트워크와 Network Connectivity Center 허브가 동일한 프로젝트에 있는 경우 VPC 네트워크의 VPC 스포크를 만들면 추가 단계 없이 즉시 허브에 연결됩니다.
VPC 네트워크와 Network Connectivity Center 허브가 서로 다른 프로젝트에 있는 경우 VPC 스포크를 만드는 프로세스는 다음과 같습니다.
허브 관리자는 다른 프로젝트의 스포크 관리자가 VPC 스포크 제안서를 만들 수 있는 IAM 정책 바인딩을 설정합니다.
참고: 허브 관리자는 언제든지 IAM 정책 바인딩을 변경할 수 있습니다. 예를 들어 허브 관리자가 나중에 액세스 권한을 취소하여 스포크 관리자가 추가 스포크 제안을 만들지 못하도록 할 수 있습니다.
이는 스포크의 자동 수락이 사용 설정되지 않은 경우에 해당합니다.
허브를 만드는 동안 허브 관리자는 기본 메시 토폴로지와 스타 토폴로지 중에서 연결 토폴로지를 선택합니다.
스포크 관리자가 VPC 스포크를 제안합니다. 스포크 제안이 스타 토폴로지를 사용하도록 구성된 허브를 위한 것인 경우 스포크 관리자는 스포크를 센터 그룹 또는 에지 그룹에 할당합니다. 메시 토폴로지의 경우 모든 스포크가 단일 기본 그룹에 속합니다.
허브 관리자는 각 스포크 제안서를 검토한 후 제안을 수락하거나 거부합니다. 다음은 제안을 수락하거나 거부한 후 허브 연결이 작동하는 방식을 설명합니다.
스포크는 허브 관리자가 스포크 제안을 수락한 후에만 활성화됩니다. Network Connectivity Center는 활성 스포크에만 네트워크 연결을 제공합니다.
허브 관리자는 이전에 수락한 VPC 스포크를 거부하여 스포크를 비활성화할 수 있습니다. 이전에 활성 상태였던 VPC 스포크가 비활성 상태가 되면 Network Connectivity Center는 스포크에 네트워크 연결을 제공하지 않습니다.
스포크 업데이트 제안 작동 방식
VPC 또는 프로듀서 VPC 스포크가 허브와 다른 프로젝트에 있는 경우 스포크의 자동 수락이 사용 설정되지 않는 한 허브 관리자가 업데이트 제안을 수락하거나 거부해야 합니다. 이러한 스포크 업데이트는 포함 또는 제외 IPv4 서브넷 범위(프리뷰)에 대한 변경사항일 수 있습니다.
허브 관리자는 허브의 스포크 그룹에 자동 수락을 사용 설정할 수 있습니다.
사용 설정하면 자동 수락 프로젝트 목록에 있는 VPC 스포크가 VPC 스포크 생성 또는 업데이트 제안 후 즉시 추가되거나 업데이트됩니다. 허브 관리자의 수동 검토 및 승인이 건너뜁니다.
허브 경로 테이블
허브 경로 테이블에는 VPC 스포크에서 가져온 서브넷 경로가 표시됩니다. 새 VPC 스포크가 생성되면, 스포크 관리자가 Google Cloud CLI의 exclude-export-ranges 플래그 또는 API의 excludeExportRanges 필드를 사용하지 않는 한 VPC 네트워크의 모든 로컬 서브넷 경로가 허브로 내보내집니다. 자세한 내용은 서브넷 경로 고유성을 참조하세요.
새 VPC 스포크를 만들면 다음 작업이 발생합니다.
스포크는 정확히 하나의 그룹에 속합니다.
각 그룹에는 해당하는 경로 테이블이 있습니다.
스포크는 해당 경로 테이블과 연결됩니다.
스포크 서브넷은 하나 이상의 경로 테이블로 전파됩니다.
메시 토폴로지 연결에는 기본 그룹이 하나뿐이므로 서브넷 경로가 단일 허브 경로 테이블로 전파됩니다. 스타 토폴로지를 지원하는 허브에 연결된 스포크는 센터와 에지라는 두 그룹 중 하나에 속합니다.
따라서 스포크 그룹마다 하나씩 연결된 두 개의 허브 경로 테이블이 생성됩니다. 센터 그룹의 스포크에는 서브넷 경로가 센터 및 에지 경로 테이블로 전파됩니다. 에지 그룹의 스포크에는 서브넷 경로가 센터 경로 테이블로 전파됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-08(UTC)"],[],[],null,["# Hub administration overview\n\nThis page provides an overview of the [Network Connectivity Center hub administrator role\n(`roles/networkconnectivity.hubAdmin`)](/network-connectivity/docs/network-connectivity-center/concepts/access-control#networkconnectivity-roles).\nAn Identity and Access Management (IAM) principal who has the hub administrator role can\ndo the following:\n\n- [Create a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub) and create Virtual Private Cloud (VPC) spokes for VPC networks that are in the same project as the hub.\n- [Give access to spoke administrators](/network-connectivity/docs/network-connectivity-center/how-to/vpc-give-access) so they can create VPC spoke proposals for VPC networks located in different projects.\n- [Review, accept, and reject VPC spoke\n proposals](/network-connectivity/docs/network-connectivity-center/how-to/vpc-review-proposed-spokes) or [set up *auto-accept* for spoke groups](/network-connectivity/docs/network-connectivity-center/how-to/vpc-review-proposed-spokes#manage_auto-accept_for_spoke_groups).\n- [View hub route tables](/network-connectivity/docs/network-connectivity-center/how-to/vpc-view-hub-route-table).\n\nCustom roles can also be used if they at least include the same permissions of\nthe Network Connectivity Center hub administrator role.\n\nHow VPC spokes join a hub\n-------------------------\n\nIf a VPC network and a Network Connectivity Center hub are located in the\nsame project, creating a VPC spoke for the VPC\nnetwork immediately establishes connectivity to the hub without any additional\nsteps.\n\nIf a VPC network and a Network Connectivity Center hub are located in\ndifferent projects, the process for creating a VPC spoke is as\nfollows:\n\n1. A hub administrator establishes IAM policy bindings that let spoke administrators in other projects create VPC *spoke\n 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](#auto-accept-projects) for spokes is not enabled.\n2. During hub creation, the hub administrator chooses the connectivity topology between the default mesh topology and star topology.\n3. A spoke administrator [proposes a VPC\n spoke](/network-connectivity/docs/network-connectivity-center/how-to/vpc-propose-a-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.\n4. 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:\n - A spoke becomes active only after a hub administrator accepts the spoke proposal. Network Connectivity Center only provides network connectivity to active spokes.\n - 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.\n\nHow spoke update proposals work\n-------------------------------\n\nWhen a VPC or a producer\nVPC spoke exists in a project different from the hub, a hub\nadministrator must accept or reject update proposals unless auto-accept for\nspokes is enabled. These spoke updates can be changes to the include or\nexclude IPv4 subnet ranges ([Preview](/products#product-launch-stages)).\n\nFor more information about updating\nspokes, see [Update a spoke](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#update-spoke).\n\n### Auto-accept projects\n\nA hub administrator can enable auto-accept for spoke groups in a hub.\nWhen enabled, VPC spokes located in the auto-accept projects\nlist are added or updated immediately after the VPC spoke\ncreation or update proposal. Manual review and approval from a hub\nadministrator is skipped.\n\nThe hub route table\n-------------------\n\nThe hub route table shows subnet routes imported from the VPC\nspokes. When a new VPC spoke is created, all *local* subnet\nroutes from the VPC network are exported to the hub *unless*\nthe spoke administrator uses the [`exclude-export-ranges`\nflag](/sdk/gcloud/reference/network-connectivity/spokes/linked-vpc-network/create#--exclude-export-ranges)\nin the Google Cloud CLI or the `excludeExportRanges` field in the API. For more\ninformation, see [subnet route\nuniqueness](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spoke-admin#subnet-uniqueness).\n\nWhen you create a new VPC spoke, the following occurs:\n\n- A spoke *belongs* to exactly one group.\n- Each group has a corresponding route table.\n- Spokes are *associated* with that route table.\n- Spoke subnets are *propagated* to one or more route tables.\n\nBecause there is only one default group in a mesh topology connectivity, the\nsubnet routes are propagated to a single hub route table. Spokes connected to a\nhub that supports star topology\nbelong to one of two different groups, namely, *center* and *edge* .\nSo, two hub route tables are generated, one associated with each\nspoke group. Spokes in the center group have their subnet routes *propagated*\nto the center and edge route tables. Spokes in the edge group have their subnet\nroutes *propagated* to the center route table.\n\nFor detailed information about connectivity topologies, see\n[Preset connectivity topologies](/network-connectivity/docs/network-connectivity-center/concepts/connectivity-topologies).\n\nGoogle Cloud automatically updates the VPC network route\ntable of each VPC spoke and the Network Connectivity Center hub route\ntable when any of the following occur:\n\n- You perform [a subnet lifecycle activity](/vpc/docs/routes#subnet-lifecycle), such as adding or deleting a subnet.\n- You add or remove VPC spokes from the hub.\n\nFor more information, see [Route tables that show subnet\nroutes](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spoke-admin#vpc-route-table)\nand [Routes](/vpc/docs/routes) in the VPC documentation.\n\nWhat's next\n-----------\n\n- To create hubs and spokes, see [Work with hubs and spokes](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes).\n- To view a list of partners whose solutions are integrated with Network Connectivity Center, see [Network Connectivity Center partners](/network-connectivity/docs/network-connectivity-center/partners).\n- To find solutions for Router appliance issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshooting-ra).\n- To get details about API and `gcloud` commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]