Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Utilizzare i Controlli di servizio VPC

Per proteggere la configurazione di Network Connectivity Center (NCC), utilizza i Controlli di servizio VPC.

I Controlli di servizio VPC forniscono ulteriore sicurezza per le API di Google e i servizi, inclusa la configurazione di NCC. Oltre a IAM, i Controlli di servizio VPC limitano i sistemi di origine che possono apportare modifiche alla configurazione di NCC.

Questa pagina descrive un caso d'uso comune e una configurazione di esempio per consentire l'accesso tra un hub NCC e spoke VPC separati da perimetri di servizio.

Per una documentazione completa, consulta la panoramica dei Controlli di servizio VPC.

Esempio: proposte di spoke VPC tra progetti in perimetri di servizio

Se la tua configurazione richiede che un hub NCC e i relativi spoke VPC si trovino in progetti diversi appartenenti a perimetri dei Controlli di servizio VPC separati, devi configurare regole in entrata e in uscita in entrambi i perimetri. In questo modo, gli amministratori degli spoke possono proporre uno spoke VPC che fa riferimento all'hub e gli amministratori dell'hub possono accettare gli spoke proposti.

L'esempio in questa pagina presuppone che l'amministratore hub e gli amministratori spoke appartengano a organizzazioni separate.

La seguente tabella riepiloga le regole richieste per questo esempio:

Perimetro	Regola	Finalità
Perimetro spoke (progetto spoke)	Regola in entrata 1	Consentire all'amministratore dello spoke di avviare una proposta di spoke creando uno spoke nel progetto spoke (se la gestione viene eseguita dall'esterno di `SpokePerimeter`)
Perimetro spoke (progetto spoke)	Regola in uscita 1	Consenti alla proposta di spoke in uscita di avviare il collegamento all'hub nel progetto hub, inclusa la verifica della rete VPC di backend
Perimetro dell'hub (progetto hub)	Regola in entrata 1	Consente all'amministratore dell'hub di gestire l'hub nel progetto hub, inclusa l'accettazione o il rifiuto delle proposte di spoke (se la gestione dell'hub avviene dall'esterno di `HubPerimeter`)
	Regola in entrata 2	Consenti alla proposta di spoke in entrata di avviare l'allegato all'hub
	Regola in uscita 1	Consenti alla proposta di spoke in entrata di richiamare il progetto spoke per completare il collegamento dello spoke all'hub, inclusa la verifica della rete VPC di backend

Regole perimetrali spoke

Per abilitare la creazione e la gestione degli spoke, l'amministratore dello spoke configura le seguenti regole in entrata e in uscita:

Regola Dettagli

Regola in entrata 1: creazione dello spoke Quando un amministratore spoke avvia una proposta spoke emettendo il comando di creazione dall'esterno del perimetro (ad esempio da una workstation amministratore, Cloud Shell o dalla console Google Cloud ), Controlli di servizio VPC valuta la chiamata come una richiesta in entrata al progetto spoke. SpokePerimeter deve consentire l'ingresso dall'identità e dall'origine di rete dell'amministratore spoke per l'API NCC.

Questa regola non è necessaria se la gestione degli spoke viene eseguita esclusivamente dall'interno di una rete VPC protetta da SpokePerimeter.

Regola in uscita 1: collegamento dell'hub e verifica della rete Quando un amministratore spoke propone uno spoke, la richiesta avvia l'allegato all'hub nel progetto hub. Nell'ambito della richiesta, l'API NCC verifica anche la rete VPC di backend utilizzando l'API Compute Engine. SpokePerimeter deve consentire il traffico in uscita dall'amministratore dello spoke sia per le API NCC che per quelle Compute Engine.

Regola	Dettagli
Regola in entrata 1: creazione dello spoke	Quando un amministratore spoke avvia una proposta spoke emettendo il comando di creazione dall'esterno del perimetro (ad esempio da una workstation amministratore, Cloud Shell o dalla console Google Cloud ), Controlli di servizio VPC valuta la chiamata come una richiesta in entrata al progetto spoke. `SpokePerimeter` deve consentire l'ingresso dall'identità e dall'origine di rete dell'amministratore spoke per l'API NCC. Questa regola non è necessaria se la gestione degli spoke viene eseguita esclusivamente dall'interno di una rete VPC protetta da `SpokePerimeter`.
Regola in uscita 1: collegamento dell'hub e verifica della rete	Quando un amministratore spoke propone uno spoke, la richiesta avvia l'allegato all'hub nel progetto hub. Nell'ambito della richiesta, l'API NCC verifica anche la rete VPC di backend utilizzando l'API Compute Engine. `SpokePerimeter` deve consentire il traffico in uscita dall'amministratore dello spoke sia per le API NCC che per quelle Compute Engine.

Definizione del perimetro spoke

Gli esempi di regole in entrata e in uscita nelle sezioni seguenti si basano sulla seguente definizione del perimetro.

Per saperne di più sui perimetri di servizio, consulta Dettagli e configurazione del perimetro di servizio.

# Spoke perimeter definition
name: accessPolicies/2345678901/servicePerimeters/SpokePerimeter
status:
  resources:
  - projects/222222222222
  restrictedServices:
  - networkconnectivity.googleapis.com
  - compute.googleapis.com
title: SpokePerimeter

Regola in entrata spoke

Questa sezione fornisce un esempio che implementa la regola in entrata per il perimetro spoke, come descritto in Regole del perimetro spoke. Questa regola è obbligatoria solo se gestisci gli spoke dall'esterno di SpokePerimeter.

Per informazioni dettagliate sulla sintassi delle regole, consulta il riferimento per le regole in entrata. Per applicare le regole, vedi Configurazione delle policy in entrata e in uscita.

echo """
# Rule 1: Allow the spoke administrator to initiate a spoke proposal by creating
# a spoke in the spoke project (if managing from outside SpokePerimeter)
- ingressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
    sources:
    - accessLevel: accessPolicies/2345678901/accessLevels/SpokeAdminAccessLevel
    # Alternatively, specify a management project or VPC network if managing
    # from a VPC network outside the perimeter:
    # - resource: projects/MANAGEMENT_PROJECT_NUMBER
  ingressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/222222222222
""" > spoke-ingress.yaml

Come best practice, definisci regole in entrata il più specifiche possibile:

identities: specifica solo l'identificatore dell'entità necessario per il tuo ambiente anziché tipi di identità generici. In questo esempio, la regola 1 specifica un account di servizio per una pipeline di deployment automatizzata. In alternativa, puoi specificare un gruppo Google per l'amministrazione del team o un account utente individuale. Per maggiori dettagli, vedi Identità supportate per le regole in entrata e in uscita.
sources: limita le origini ai livelli di accesso noti. Questo esempio specifica un livello di accesso dalla norma di accesso che gestisce SpokePerimeter per autorizzare fonti esterne come workstation amministrative, Cloud Shell o la console Google Cloud . In alternativa, puoi consentire l'accesso da una rete VPC di gestione esterna al perimetro utilizzando l'attributo - resource: per specificare il progetto o la rete VPC. Per maggiori dettagli, vedi Consentire l'accesso dall'esterno di un perimetro e Accesso sensibile al contesto con regole in entrata.
operations: le limitazioni per networkconnectivity.googleapis.com vengono applicate a livello di servizio, richiedendo method: "*". Per questo servizio non sono disponibili metodi più granulari.
resources: specifica il numero esatto del progetto spoke in resources. Evita i caratteri jolly (*).

Regola in uscita dello spoke

Questa sezione fornisce un esempio che implementa la regola di uscita per il perimetro spoke, come descritto in Regole del perimetro spoke.

Per informazioni dettagliate sulla sintassi delle regole, consulta il riferimento per le regole in uscita.

echo """
# Rule 1: Allow the outbound spoke proposal to initiate attachment to the hub in
# the hub project, which includes verifying the backing VPC network
- egressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: NetworksService.Get
    resources:
    - projects/111111111111
  egressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
""" > spoke-egress.yaml

Come best practice, definisci regole in uscita il più specifiche possibile:

identities: specifica solo l'identificatore dell'entità necessario per il tuo ambiente anziché tipi di identità generici. In questo esempio, la regola 1 specifica un account di servizio per una pipeline di deployment automatizzata. In alternativa, puoi specificare un gruppo Google per l'amministrazione del team o un account utente individuale. Per maggiori dettagli, vedi Identità supportate per le regole in entrata e in uscita.
operations: le limitazioni per networkconnectivity.googleapis.com vengono applicate a livello di servizio, richiedendo method: "*". Per compute.googleapis.com, specifica method: NetworksService.Get per concedere l'autorizzazione a verificare la rete VPC di backend quando viene avviato l'allegato all'hub.
resources: specifica il numero esatto del progetto hub in resources. Evita i caratteri jolly (*).

Regole del perimetro dell'hub

Per abilitare l'amministrazione dell'hub e consentire le proposte di spoke in entrata, l'amministratore dell'hub configura le seguenti regole in entrata e in uscita:

Regola	Dettagli
Regola in entrata 1: gestione dell'hub	Quando un amministratore hub gestisce l'hub dall'esterno del perimetro (ad esempio da una workstation amministratore, Cloud Shell o dalla console Google Cloud ), Controlli di servizio VPC valuta la chiamata come una richiesta di traffico in entrata al progetto hub. Questa regola consente all'amministratore dell'hub di esaminare gli spoke proposti e accettarli (trasformando lo spoke in `ACTIVE`) o rifiutarli (trasformando lo spoke in `REJECTED`). `HubPerimeter` deve consentire l'ingresso dall'identità e dall'origine di rete dell'amministratore dell'hub. Questa regola non è necessaria se la gestione dell'hub viene eseguita esclusivamente dall'interno di una rete VPC protetta da `HubPerimeter`.
Regola in entrata 2: allegato dell'hub	Quando un amministratore spoke propone uno spoke, la richiesta avvia l'allegato all'hub nel progetto hub. `HubPerimeter` deve consentire l'accesso in entrata dall'identità e dall'origine di rete dell'amministratore dello spoke per l'API NCC nei perimetri di servizio.
Regola di uscita 1: collegamento spoke e verifica della rete	Quando un amministratore dello spoke propone uno spoke, la richiesta richiama il progetto spoke per completare il collegamento dello spoke all'hub e impostare lo stato dello spoke su `PENDING_REVIEW`. Nell'ambito della richiesta, l'API NCC verifica anche la rete VPC di backend utilizzando l'API Compute Engine. `HubPerimeter` deve consentire il traffico in uscita dall'amministratore dello spoke per le API NCC e Compute Engine.

Definizione del perimetro dell'hub