Panoramica della rete VPC condivisa

Una rete VPC condivisa consente a un'organizzazione di connettere risorse di più progetti a una rete Virtual Private Cloud (VPC) in comune, in modo che possano comunicare tra loro in modo sicuro ed efficiente utilizzando IP interni di quella rete. Quando utilizzi una rete VPC condivisa, designi un progetto come progetto host, a cui colleghi uno o più progetti di servizi. Le reti VPC nel progetto host sono chiamate reti VPC condivise. Le risorse idonee dei progetti di servizio possono utilizzare subnet della rete VPC condivisa.

Una rete VPC condivisa consente agli amministratori dell'organizzazione di delegare le responsabilità amministrative, ad esempio creazione e gestione delle istanze, agli amministratori dei progetti di servizio, mantenendo al contempo il controllo centralizzato sulle risorse di rete come subnet, route e firewall. Questo modello permette alle organizzazioni di:

  • Implementare una best practice di sicurezza del privilegio minimo per l'amministrazione, l'auditing e il controllo degli accessi della rete. Gli amministratori della rete VPC condivisa possono delegare le attività di amministrazione della rete agli amministratori della rete e della sicurezza nella rete VPC condivisa, senza consentire agli amministratori dei progetti di servizio di apportare modifiche che influiscono sulla rete. Gli amministratori dei progetti di servizio possono solo creare e gestire istanze che utilizzano la rete VPC condiviso. Per maggiori dettagli, consulta la sezione Amministratori e IAM.
  • Applicare e imporre criteri di controllo dell'accesso coerenti a livello di rete per più progetti di servizio nell'organizzazione delegando le responsabilità amministrative. Ad esempio, gli amministratori dei progetti di servizio possono essere amministratori di istanze Compute nel progetto, creando ed eliminando istanze che utilizzano subnet approvate nel progetto host del VPC condiviso.
  • Utilizza i progetti di servizio per separare i budget o i centri di costo interni. Per ulteriori dettagli, consulta la sezione Fatturazione.

Concetti

Organizzazioni, cartelle e progetti

Una rete VPC condivisa collega i progetti all'interno della stessa organizzazione. I progetti collegati possono trovarsi nella stessa cartella o in cartelle diverse, ma se si trovano in cartelle diverse, l'amministratore deve avere i diritti Amministratore VPC condiviso per entrambe le cartelle. Fai riferimento alla gerarchia delle risorse di Google Cloud per ulteriori informazioni su organizzazioni, cartelle e progetti.

I progetti host e di servizio partecipanti non possono appartenere a organizzazioni diverse. L'unica eccezione riguarda la migrazione dei progetti da un'organizzazione a un'altra. Durante la migrazione, i progetti di servizio possono trovarsi temporaneamente in un'organizzazione diversa da quella del progetto host. Per ulteriori informazioni sulla migrazione dei progetti, consulta la sezione Migrazione dei progetti.

Un progetto che partecipa al VPC condiviso è un progetto host o un progetto di servizio:

  • Un progetto host contiene una o più reti VPC condivise. Un amministratore della rete VPC condivisa deve prima abilitare un progetto come progetto host. Successivamente, un amministratore del VPC condiviso può collegare uno o più progetti di servizio.

  • Un progetto di servizio è un qualsiasi progetto collegato a un progetto host da un amministratore del VPC condiviso. Questo allegato consente di partecipare alla rete VPC condivisa. È prassi comune fare in modo che più progetti di servizio vengano gestiti e amministrati da reparti o team diversi della tua organizzazione.

  • Un progetto non può essere contemporaneamente un progetto host e un progetto di servizio. Pertanto, un progetto di servizio non può essere un progetto host per ulteriori progetti di servizio.

  • Puoi creare e utilizzare più progetti host, ma ogni progetto di servizio può essere associato a un solo progetto host. Per un'illustrazione, vedi l'esempio di più progetti host.

  • Nel progetto host puoi creare reti, subnet, intervalli di indirizzi secondari, regole firewall e altre risorse di rete. Il progetto host può quindi condividere le subnet selezionate, inclusi gli intervalli secondari, con i progetti di servizio. I servizi in esecuzione in un progetto di servizio possono utilizzare il VPC condiviso per comunicare con le risorse in esecuzione negli altri progetti di servizio.

Per chiarezza, un progetto che non partecipa al VPC condiviso è chiamato progetto autonomo. Questo evidenzia che non è né un progetto host né un progetto di servizio.

Una rete VPC autonoma è una rete VPC non condivisa esistente in un progetto autonomo o in un progetto di servizio.

Reti

Una rete VPC condivisa è una rete VPC definita in un progetto host e resa disponibile come rete condivisa a livello centrale per le risorse idonee nei progetti di servizio. Le reti VPC condivise possono essere in modalità automatica o personalizzata, ma le reti legacy non sono supportate.

Quando un progetto host è abilitato, sono disponibili due opzioni per la condivisione delle reti:

  • Puoi condividere tutte le subnet dei progetti host. Se selezioni questa opzione, verranno condivise anche eventuali nuove subnet create nel progetto host, comprese quelle nelle nuove reti.
  • Puoi specificare le singole subnet da condividere. Se condividi le singole subnet, vengono condivise solo le subnet a meno che non modifichi manualmente l'elenco.

I progetti host e di servizio sono collegati da allegati a livello di progetto. Le subnet delle reti VPC condivise nel progetto host sono accessibili dagli amministratori del progetto di servizio come descritto nella sezione successiva, Amministratori e IAM.

Vincoli dei criteri dell'organizzazione

I criteri dell'organizzazione e le autorizzazioni IAM collaborano per fornire diversi livelli di controllo dell'accesso. I criteri dell'organizzazione consentono di impostare i controlli a livello di organizzazione, cartella o progetto.

Se sei un amministratore dei criteri dell'organizzazione, puoi specificare i seguenti vincoli di VPC condiviso in un criterio dell'organizzazione:

  • Puoi limitare l'insieme di progetti host a cui possono essere associati un progetto o un progetto non host in una cartella o in un'organizzazione. Il vincolo si applica quando un amministratore del VPC condiviso collega un progetto di servizio con un progetto host. Il vincolo non influisce sugli allegati esistenti. Gli allegati esistenti rimangono invariati anche se un criterio nega nuovi. Per ulteriori informazioni, consulta il vincolo constraints/compute.restrictSharedVpcHostProject.

  • Puoi specificare le subnet VPC condivise a cui un progetto di servizio può accedere a livello di progetto, cartella o organizzazione. Il vincolo si applica quando crei nuove risorse nelle subnet specificate e non influisce sulle risorse esistenti. Le risorse esistenti continuano a funzionare normalmente nelle loro subnet anche se un criterio impedisce l'aggiunta di nuove risorse. Per ulteriori informazioni, consulta il vincolo constraints/compute.restrictSharedVpcSubnetworks.

Amministratori e IAM

Una rete VPC condivisa utilizza i ruoli Identity and Access Management (IAM) per l'amministrazione delegata. I ruoli seguenti possono essere concessi ai principali IAM, come utenti, gruppi Google, domini Google o account di servizio Google Cloud. Se devi contattare uno di questi amministratori, puoi cercarlo nel criterio IAM della tua organizzazione o del tuo progetto. Se non disponi delle autorizzazioni necessarie, devi contattare un amministratore di rete o di progetto nella tua organizzazione.

Ruoli amministrativi obbligatori

Amministratore (ruolo IAM) Scopo
Amministratore dell'organizzazione (resourcemanager.organizationAdmin)
• Entità IAM nell'organizzazione
Gli amministratori dell'organizzazione hanno il ruolo resourcemanager.organizationAdmin per la tua organizzazione. Hanno designato gli amministratori dei VPC condivisi assegnando loro ruoli di creazione ed eliminazione dei progetti appropriati e il ruolo di amministratore della rete VPC condivisa per l'organizzazione. Questi amministratori possono definire criteri a livello di organizzazione, ma azioni specifiche per cartella e progetto richiedono ruoli aggiuntivi per cartelle e progetti.
Amministratore del VPC condiviso
(compute.xpnAdmin e
resourcemanager.projectIamAdmin)
• Entità IAM nell'organizzazione, o
• Entità IAM in una cartella (beta)
Gli amministratori dei VPC condivisi hanno i ruoli Amministratore VPC condiviso di Compute (compute.xpnAdmin) e Amministratore IAM progetto (resourcemanager.projectIamAdmin) per l'organizzazione o una o più cartelle. Esegue varie attività necessarie per configurare la rete VPC condivisa, come abilitare i progetti host, collegare i progetti di servizio ai progetti host e delegare l'accesso ad alcune o tutte le subnet nelle reti VPC condivise per gli amministratori dei progetti di servizio. In genere, il proprietario di un progetto host è anche un amministratore del VPC condiviso.
Un utente a cui è stato assegnato il ruolo Amministratore VPC condiviso di Compute per l'organizzazione dispone di quel ruolo per tutte le cartelle dell'organizzazione. Un utente a cui è stato assegnato un ruolo per una cartella ha quel ruolo per quella cartella e qualsiasi cartella nidificata al di sotto. Un amministratore del VPC condiviso può collegare progetti in due cartelle diverse solo se l'amministratore ha il ruolo di entrambe le cartelle.
Amministratore progetto di servizio
(compute.networkUser)
• Entità IAM nell'organizzazione, o
entità IAM in un progetto host o
• entità IAM in alcune subnet nel progetto host
Un amministratore del VPC condiviso definisce un amministratore di progetto di servizio concedendo a un'entità IAM il ruolo Utente di rete (compute.networkUser) per l'intero progetto host o le subnet delle relative reti VPC condivise. Gli amministratori dei progetti di servizio mantengono anche la proprietà e il controllo sulle risorse definite nei progetti di servizio, quindi devono avere il ruolo Amministratore di istanze (compute.instanceAdmin) ai progetti di servizio corrispondenti. Possono avere ruoli IAM aggiuntivi ai progetti di servizio, come il proprietario.

Amministratori progetto di servizio

Durante la definizione di ogni amministratore del progetto di servizio, un amministratore del VPC condiviso può concedere l'autorizzazione a utilizzare l'intero progetto host o solo alcune subnet:

  • Autorizzazioni a livello di progetto: è possibile definire un amministratore del progetto di servizio che disponga dell'autorizzazione per utilizzare tutte le subnet nel progetto host se l'amministratore del VPC condiviso concede il ruolo di compute.networkUser per l'intero progetto host all'amministratore del progetto di servizio. Il risultato è che l'amministratore del progetto di servizio è autorizzato a utilizzare tutte le subnet di tutte le reti VPC del progetto host, incluse le subnet e le reti VPC aggiunte al progetto host in futuro.

  • Autorizzazioni a livello di subnet: in alternativa, a un amministratore di progetto di servizio può essere concesso un insieme più restrittivo di autorizzazioni per utilizzare solo alcune subnet se l'amministratore del VPC condiviso concede il ruolo di compute.networkUser per le subnet selezionate all'amministratore del progetto di servizio. Un amministratore del progetto di servizio che dispone solo di autorizzazioni a livello di subnet può utilizzare solo tali subnet. Una volta aggiunte al progetto host nuove reti VPC condivise o nuove subnet, un amministratore del VPC condiviso dovrebbe esaminare le associazioni di autorizzazioni per il ruolo compute.networkUser per garantire che le autorizzazioni a livello di subnet per tutti gli amministratori dei progetti di servizio corrispondano alla configurazione prevista.

Amministratori di rete e della sicurezza

Gli amministratori della rete VPC condivisa hanno il controllo completo sulle risorse nel progetto host, inclusa l'amministrazione della rete VPC condivisa. Facoltativamente, possono delegare determinate attività amministrative di rete ad altre entità IAM:

Amministratore Scopo
Amministratore di rete
• Entità IAM nel progetto host o
• Entità IAM nell'organizzazione
Un amministratore del VPC condiviso definisce un amministratore di rete concedendo a un'entità IAM il ruolo Amministratore di rete (compute.networkAdmin) al progetto host. Gli amministratori di rete hanno il controllo completo su tutte le risorse di rete, ad eccezione delle regole firewall e dei certificati SSL.
Amministratore della sicurezza
• Entità IAM nel progetto host o
• Entità IAM nell'organizzazione
Un amministratore del VPC condiviso può definire un amministratore di sicurezza concedendo a un'entità IAM il ruolo Amministratore sicurezza (compute.securityAdmin) al progetto host. Gli amministratori della sicurezza gestiscono le regole firewall e i certificati SSL.

Specifiche

Quote e limiti

I progetti host del VPC condiviso sono soggetti alle quote VPC specifiche per progetto. Le reti VPC condivise sono soggette ai limiti per rete e ai limiti per istanza per le reti VPC. Inoltre, le relazioni tra i progetti host e di servizio sono regolate da limiti specifici per le reti VPC condivise.

Fatturazione

La fatturazione per le risorse che partecipano a una rete VPC condivisa viene attribuita al progetto di servizio in cui si trova la risorsa, anche se quest'ultima utilizza la rete VPC condivisa nel progetto host.

  • Le tariffe e le regole utilizzate per calcolare gli importi di fatturazione per le risorse nei progetti di servizio che utilizzano una rete VPC condivisa sono le stesse di quelle che hanno trovato le risorse nel progetto host stesso.
  • La fatturazione per il traffico in uscita generato da una risorsa è attribuita al progetto in cui è definita la risorsa:
    • Il traffico in uscita da un'istanza viene attribuito al progetto che la contiene. Ad esempio, se un'istanza viene creata in un progetto di servizio ma utilizza una rete VPC condivisa, qualsiasi fatturazione per il traffico in uscita che genera viene attribuita al suo progetto di servizio. In questo modo puoi utilizzare VPC condiviso per organizzare le risorse in centri di costo per la tua organizzazione.
    • I costi associati a un bilanciatore del carico vengono addebitati al progetto contenente i componenti del bilanciatore del carico. Per maggiori dettagli sul bilanciamento del carico e sulla rete VPC condivisa, consulta la sezione del bilanciamento del carico.
    • Il traffico in uscita verso le VPN viene attribuito al progetto che contiene la risorsa gateway VPN. Ad esempio, se nella rete VPC condiviso viene creato un gateway VPN, questo viene contenuto nel progetto host. Il traffico in uscita attraverso il gateway VPN, indipendentemente dal progetto di servizio che avvia il traffico in uscita, viene attribuito al progetto host.
    • I costi del traffico proveniente da una risorsa in un progetto di servizio VPC condiviso che avviene in uscita tramite un collegamento VLAN vengono attribuiti al progetto proprietario del collegamento VLAN. Per ulteriori informazioni, consulta la pagina dei prezzi di Cloud Interconnect.

Limitazioni

La prenotazione di un indirizzo IPv6 esterno a livello di area geografica è disponibile come funzionalità di anteprima limitata. Tuttavia, se prenoti un indirizzo IPv6 esterno a livello di area geografica statico nella rete VPC in un progetto di servizio, il valore dell'indirizzo IP deve provenire da una subnet nella stessa rete VPC. Non puoi riservare un indirizzo IPv6 a livello di area geografica statico proveniente da una subnet condivisa nel progetto host. Puoi prenotare solo indirizzi IPv6 esterni a livello di area geografica da una subnet nella tua rete VPC.

Risorse

Risorse idonee

Puoi utilizzare la maggior parte dei prodotti e delle funzionalità di Google Cloud nei progetti di servizio del VPC condiviso.

Le seguenti limitazioni si applicano alle risorse idonee alla partecipazione a uno scenario VPC condiviso:

  • L'utilizzo di una rete VPC condivisa non è obbligatorio. Ad esempio, gli amministratori di istanze possono creare istanze nel progetto di servizio che utilizzano una rete VPC in quel progetto. Le reti definite nei progetti di servizio non vengono condivise.

  • Alcune risorse devono essere ricreate per utilizzare una rete VPC condivisa. Quando un amministratore del VPC condiviso collega un progetto esistente a un progetto host, diventa un progetto di servizio, ma le risorse esistenti non usano automaticamente le risorse della rete condivisa. Per utilizzare una rete VPC condivisa, un amministratore del progetto Service deve creare una risorsa idonea e configurarla in modo che utilizzi una subnet di una rete VPC condivisa. Ad esempio, un'istanza esistente in un progetto di servizio non può essere riconfigurata per l'utilizzo di una rete VPC condivisa, ma è possibile crearne una nuova per utilizzare le subnet disponibili in una rete VPC condivisa. Questa limitazione si applica alle zone private.

Indirizzi IP

Quando crei un'istanza in un progetto di servizio, puoi configurarla come istanza a stack singolo (solo IPv4) o a doppio stack (IPv4 e IPv6), a seconda della configurazione della subnet del progetto host. Per ulteriori informazioni, consulta Creazione di un'istanza.

Le istanze nei progetti di servizio collegati a un progetto host utilizzando la stessa rete VPC condivisa possono comunicare tra loro usando i loro indirizzi IPv4 interni o i loro indirizzi IPv6 interni o esterni, soggetti alle regole firewall applicabili.

Un indirizzo IP temporaneo può essere assegnato automaticamente a un'istanza in un progetto di servizio. Ad esempio, quando gli amministratori del progetto di servizio creano le istanze, selezionano la rete VPC condivisa e una subnet condivisa disponibile. L'indirizzo IPv4 interno dell'istanza proviene dall'intervallo di indirizzi IP disponibili disponibili nell'intervallo di indirizzi IPv4 condiviso della subnet condivisa. Se configurano l'istanza come un'istanza a doppio stack, l'indirizzo IPv6 dell'istanza proviene dall'intervallo di indirizzi IP disponibili nell'intervallo di subnet condiviso selezionato.

Gli indirizzi IPv4 temporanei possono anche essere assegnati automaticamente ai bilanciatori del carico interni. Per ulteriori informazioni, consulta la pagina Creare bilanciatori del carico TCP/UDP interni o Creare bilanciatori del carico HTTP(S) interni.

In alternativa, un amministratore del progetto di servizio può scegliere di prenotare un indirizzo IPv4 interno statico. L'oggetto indirizzo IPv4 interno deve essere creato nello stesso progetto di servizio della risorsa che lo utilizza, anche se il valore dell'indirizzo IP proviene dagli indirizzi IPv4 disponibili della subnet condivisa selezionata in una rete VPC condivisa. Per ulteriori informazioni, consulta la pagina relativa alla prenotazione di un IP interno statico nella pagina del provisioning del VPC condiviso.

Gli oggetti indirizzo IPv4 esterni definiti nel progetto host possono essere utilizzati dalle risorse nel progetto host o in qualsiasi progetto di servizio associato. I progetti di servizio possono anche utilizzare i propri oggetti indirizzi IPv4 esterni. Ad esempio, un'istanza in un progetto di servizio può utilizzare un indirizzo IPv4 esterno a livello di area geografica definito nel progetto di servizio o nel progetto host.

La prenotazione degli indirizzi IP dei progetti host dai progetti di servizio non è supportata per gli indirizzi IPv6.

DNS interno

Le VM nello stesso progetto di servizio possono connettersi tra loro utilizzando i nomi DNS interni che Google Cloud crea automaticamente. Questi nomi DNS utilizzano l'ID progetto del progetto di servizio in cui vengono create le VM, anche se i nomi rimandano a indirizzi IP interni nel progetto host. Per una spiegazione completa, consulta la sezione Nomi DNS interni e VPC condiviso nella documentazione DNS interno.

Zone private di Cloud DNS

Puoi utilizzare le zone private di Cloud DNS in una rete VPC condivisa. Puoi creare la zona privata nel progetto host e autorizzare l'accesso alla zona per la rete VPC condiviso oppure configurare la zona in un progetto di servizio utilizzando l'associazione tra progetti.

Bilanciamento del carico

La rete VPC condivisa può essere utilizzata insieme al bilanciamento del carico.

La tabella seguente riepiloga i punti in cui devono essere creati i componenti di bilanciamento del carico. Nella maggior parte dei casi, le istanze di backend vengono create in un progetto di servizio. In tal caso, tutti i componenti del bilanciatore del carico vengono creati in quel progetto. Sebbene sia possibile creare istanze di backend nel progetto host, questa configurazione non è adatta ai deployment VPC comuni tipici, in quanto non separa le responsabilità di amministrazione del servizio e dello sviluppo dei servizi.

Bilanciatore del carico Indirizzo IP Regola di forwarding Proxy di destinazione e mappa URL Componenti di backend
Bilanciamento del carico TCP/UDP interno Consulta la sezione relativa all'architettura VPC condivisa nella panoramica del bilanciamento del carico TCP/UDP interno e nella creazione di un bilanciatore del carico TCP/UDP interno nella documentazione del provisioning condiviso di VPC.
Bilanciamento del carico TCP/UDP esterno È necessario definire un indirizzo IP esterno a livello di area geografica nello stesso progetto del bilanciatore del carico o del progetto host del VPC condiviso. Una regola di forwarding esterno a livello di area geografica deve essere definita nello stesso progetto del servizio di backend o del pool di destinazione del bilanciatore del carico.
Consulta l'architettura VPC condivisa nella documentazione del bilanciatore del carico di rete per i dettagli relativi al bilanciamento del carico di rete basato su servizio di backend.
Non applicabile. Il servizio di backend o pool di destinazione deve essere definito nello stesso progetto e nella stessa area geografica in cui si trovano le istanze di backend. I controlli di integrità devono essere definiti nello stesso progetto.
Bilanciatore del carico HTTP(S) esterno globale È necessario definire un indirizzo IP esterno nello stesso progetto del bilanciatore del carico o del progetto host del VPC condiviso. La regola di forwarding esterna deve essere definita nello stesso progetto delle istanze di backend (il progetto di servizio). Il proxy HTTP di destinazione o proxy HTTPS di destinazione e la mappa URL associata devono essere definiti nello stesso progetto delle istanze di backend. Un servizio di backend globale deve essere definito nello stesso progetto delle istanze di backend. Queste istanze devono essere in gruppi di istanze collegati al servizio di backend come backend. I controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto anche nel servizio di backend.
Bilanciatore del carico HTTP(S) esterno globale (classico)
Bilanciatore del carico HTTP(S) esterno a livello di area geografica

Puoi creare la rete, le subnet e gli indirizzi IP richiesti nel progetto host. Quindi, per i componenti del bilanciatore del carico, puoi eseguire una delle seguenti operazioni:

  • Crea la regola di forwarding per il bilanciatore del carico, il proxy di destinazione e la mappa URL in un progetto host o di servizio; crea i servizi di backend e i backend in più progetti di servizio come richiesto. La mappa degli URL può fare riferimento ai servizi di backend in più progetti di servizio nell'ambiente VPC condiviso. Questo è anche noto come riferimento a servizi multiprogetto. Questo caso d'uso è in anteprima.
  • Crea il bilanciatore del carico e i backend in un progetto di servizio.
  • (Opzione sconsigliata) Crea il bilanciatore del carico e i backend in un progetto host.

I controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto del servizio di backend.

Per ulteriori dettagli, vedi:

Bilanciamento del carico HTTP(S) interno
Bilanciamento del carico del proxy SSL È necessario definire un indirizzo IP esterno nello stesso progetto del bilanciatore del carico. La regola di forwarding esterna deve essere definita nello stesso progetto delle istanze di backend (il progetto di servizio). Il proxy SSL di destinazione deve essere definito nello stesso progetto delle istanze di backend. Un servizio di backend globale deve essere definito nello stesso progetto delle istanze di backend. Queste istanze devono essere in gruppi di istanze collegati al servizio di backend come backend. I controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto anche nel servizio di backend.
Bilanciamento del carico del proxy TCP È necessario definire un indirizzo IP esterno nello stesso progetto del bilanciatore del carico. La regola di forwarding esterna deve essere definita nello stesso progetto delle istanze di backend (il progetto di servizio). Il proxy TCP di destinazione deve essere definito nello stesso progetto delle istanze di backend. Un servizio di backend globale deve essere definito nello stesso progetto delle istanze di backend. Queste istanze devono essere in gruppi di istanze collegati al servizio di backend come backend. I controlli di integrità associati ai servizi di backend devono essere definiti nello stesso progetto anche nel servizio di backend.

Esempi e casi d'uso

Concetti di base

Il seguente esempio illustra un semplice scenario VPC condiviso:

Concetti di base (fai clic per ingrandire)
Concetti di base (fai clic per ingrandire)
  • Un amministratore del VPC condiviso per l'organizzazione ha creato un progetto host e vi hanno collegato due progetti di servizio:

    • Gli amministratori dei progetti di servizio in Service Project A possono essere configurati per accedere a tutte o ad alcune delle subnet nella rete VPC condiviso. Un amministratore di progetto di servizio con almeno autorizzazioni a livello di subnet per 10.0.1.0/24 Subnet ha creato Instance A in una zona dell'area geografica us-west1. Questa istanza riceve il suo indirizzo IP interno, 10.0.1.3, dal blocco CIDR 10.0.1.0/24.

    • Gli amministratori dei progetti di servizio in Service Project B possono essere configurati per accedere a tutte o ad alcune delle subnet nella rete VPC condiviso. Un amministratore di progetto di servizio con almeno autorizzazioni a livello di subnet per 10.15.2.0/24 Subnet ha creato Instance B in una zona dell'area geografica us-east1. Questa istanza riceve il suo indirizzo IP interno, 10.15.2.4, dal blocco 10.15.2.0/24CIDR.

  • Il progetto autonomo non partecipa al VPC condiviso, né è un progetto host o di servizio. Le istanze autonome vengono create dalle entità IAM che hanno almeno il ruolo compute.InstanceAdmin per il progetto.

Progetti host multipli

L'esempio seguente mostra come può essere utilizzato un VPC condiviso per creare ambienti di test e produzione separati. Per questo caso, un'organizzazione ha deciso di utilizzare due progetti host separati, un ambiente di test e un ambiente di produzione.

Progetti host multipli (fai clic per ingrandire)
Più progetti host (fai clic per ingrandire)
  • Un amministratore del VPC condiviso per l'organizzazione ha creato due progetti host e vi hanno allegato due progetti di servizio nel seguente modo:

    • I progetti di servizio Apps Testing e Mobile Testing sono collegati al progetto host Test Environment. Gli amministratori dei progetti di servizio in ogni progetto possono essere configurati per accedere a tutte o ad alcune delle subnet in Testing Network.

    • I progetti di servizio Apps Production e Mobile Production sono collegati al progetto host Production Environment. Gli amministratori dei progetti di servizio in ogni progetto possono essere configurati per accedere a tutte o ad alcune delle subnet in Production Network.

  • Entrambi i progetti host hanno una rete VPC condivisa con subnet configurate per l'utilizzo degli stessi intervalli CIDR. In Testing Network e in Production Network, le due subnet sono:

    • 10.0.1.0/24 Subnet nell'area geografica us-west1

    • 10.15.2.0/24 Subnet nell'area geografica us-east1

  • Considera Instance AT nel progetto di servizio Apps Testing e Instance AP nel progetto di servizio Apps Production:

    • Gli amministratori dei progetti di servizio possono creare istanze come queste, a condizione che dispongano almeno delle autorizzazioni a livello di subnet per 10.0.1.0/24 Subnet.

    • Tieni presente che entrambe le istanze utilizzano l'indirizzo IP 10.0.1.3. Ciò è accettabile perché ogni istanza esiste in un progetto di servizio associato a un progetto host univoco contenente la propria rete VPC condivisa. Le reti di test e produzione sono state configurate specificatamente allo stesso modo.

    • Le istanze che utilizzano 10.0.1.0/24 Subnet devono trovarsi in una zona nella stessa area geografica della subnet, anche se la subnet e le istanze sono definite in progetti separati. Poiché 10.0.1.0/24 Subnet si trova nell'area geografica us-west1, gli amministratori dei progetti di servizio che creano istanze che utilizzano la subnet devono scegliere una zona nella stessa area geografica, ad esempio us-west1-a.

Scenario del cloud ibrido

L'esempio seguente mostra come è possibile utilizzare un VPC condiviso in un ambiente ibrido.

Cloud ibrido (fai clic per ingrandire)
Cloud ibrido (clic per ingrandire)

Per questo esempio, un'organizzazione ha creato un singolo progetto host con una singola rete VPC condivisa. La rete VPC condivisa è connessa tramite Cloud VPN a una rete on-premise. Alcuni servizi e applicazioni sono ospitati in Google Cloud, mentre altri sono conservati on-premise:

  • Un amministratore del VPC condiviso ha abilitato il progetto host e vi ha connesso tre progetti di servizio: Service Project A, Service Project B e Service Project C.

    • Team separati possono gestire tutti i progetti di servizio. Le autorizzazioni IAM sono state configurate in modo tale che un amministratore di progetto per un progetto non abbia autorizzazioni per gli altri progetti di servizio.

    • L'amministratore del VPC condiviso ha concesso le autorizzazioni a livello di subnet o di progetto agli amministratori dei progetti di servizio necessari per creare istanze che utilizzano la rete VPC condivisa:

      • Un amministratore del progetto di servizio per Service Project A che dispone di autorizzazioni a livello di subnet per 10.0.1.0/24 Subnet può creare Instance A al suo interno. L'amministratore del progetto di servizio deve scegliere una zona nell'area geografica us-west1 per l'istanza, perché questa è l'area geografica che contiene 10.0.1.0/24 Subnet. Instance A riceve il suo indirizzo IP, 10.0.1.3, dall'intervallo di indirizzi IP gratuiti in 10.0.1.0/24 Subnet.

      • Un amministratore del progetto di servizio per Service Project B, che dispone di autorizzazioni a livello di subnet per 10.15.2.0/24 Subnet, può creare Instance B all'interno. L'amministratore del progetto di servizio deve scegliere una zona nell'area geografica us-east1 per l'istanza, perché questa è l'area geografica che contiene 10.15.2.0/24 Subnet. Instance B riceve il suo indirizzo IP, 10.15.2.4, dall'intervallo di indirizzi IP gratuiti in 10.15.2.0/24 Subnet.

      • Un amministratore di progetto di servizio per Service Project C, che dispone di autorizzazioni a livello di progetto per l'intero progetto host, può creare istanze in qualsiasi subnet in qualsiasi rete VPC del progetto host. Ad esempio, l'amministratore del progetto di servizio può creare Instance C nell'area geografica 10.7.1.0/24 Subnet, scegliendo una zona nell'area geografica us-east1 in modo che corrisponda all'area geografica per la subnet. Instance C riceve il suo indirizzo IP, 10.7.1.50, dall'intervallo di indirizzi IP gratuiti in 10.7.1.0/24 Subnet.

    • Ogni progetto di servizio viene fatturato separatamente.

    • Gli amministratori dei progetti di servizio in ogni progetto sono responsabili della creazione e gestione delle risorse.

  • Un amministratore del VPC condiviso ha delegato le attività di amministrazione della rete ad altri provider IAM che sono amministratori della rete e della sicurezza per la rete VPC condivisa.

    • Un amministratore di rete ha creato un gateway Cloud VPN e configurato un tunnel VPN tramite Internet a un gateway on-premise. Cloud VPN scambia e riceve route con la sua controparte on-premise perché è stato configurato un router Cloud corrispondente nella stessa us-east1area geografica .

    • Se la modalità di routing dinamico del VPC è globale, il router Cloud applica le route apprese alla rete on-premise in tutte le subnet della rete VPC e condivide le route a tutte le subnet VPC con la rispettiva controparte on-premise.

    • Gli amministratori della sicurezza creano e gestiscono le regole firewall nella rete VPC condiviso per controllare il traffico tra le istanze in Google Cloud e nella rete on-premise.

    • In base alle regole firewall applicabili, le istanze nei progetti di servizio possono essere configurate per comunicare con servizi interni, come database o server di directory on-premise.

Servizio web a due livelli

L'esempio seguente mostra come utilizzare il VPC condiviso per delegare le responsabilità amministrative e mantenere il principio del privilegio minimo. In questo caso, un'organizzazione dispone di un servizio web separato in due livelli e i team sono gestiti da team diversi. Il Livello 1 rappresenta il componente rivolto esternamente, dietro a un bilanciatore del carico HTTP(S). Il Livello 2 rappresenta un servizio interno su cui si basa il Livello 1 ed è bilanciato utilizzando un bilanciatore del carico TCP/UDP interno.

Servizio web a due livelli (fai clic per ingrandire)
Servizio web a due livelli (fai clic per ingrandire)

Una rete VPC condivisa consente di mappare ogni livello del servizio web a progetti diversi, in modo che possano essere gestiti da team diversi durante la condivisione di una rete VPC comune:

  • Le risorse, ad esempio istanze e componenti del bilanciatore del carico, per ogni livello vengono posizionate nei singoli progetti di servizio gestiti da team diversi.

  • Ogni progetto di servizio di livello è stato collegato al progetto host da un amministratore del VPC condiviso. Anche il progetto host condiviso ha abilitato il progetto host.

    • Team separati possono gestire ogni livello del servizio web in quanto amministratore del progetto di servizio nel progetto di servizio appropriato.

    • Ogni progetto di servizio viene fatturato separatamente.

    • Gli amministratori dei progetti di servizio in ogni progetto sono responsabili della creazione e gestione delle risorse.

  • Il controllo dell'accesso alla rete è definito come segue:

    • Le entità IAM che lavorano solo al livello 1 sono amministratori di progetti di servizio per Tier 1 Service Project e ricevono autorizzazioni a livello di subnet solo per 10.0.1.0/24 Subnet. In questo esempio, uno di questi amministratori del progetto di servizio ha creato tre Tier 1 Instances in quella subnet.

    • Le entità IAM che lavorano solo al livello 2 sono amministratori di progetti Service per Tier 2 Service Project e ricevono autorizzazioni a livello di subnet solo per 10.0.2.0/24 Subnet. In questo esempio, un altro amministratore del progetto di servizio ha creato tre Tier 2 Instances in quella subnet insieme a un bilanciatore del carico interno la cui regola di forwarding utilizza un indirizzo IP dell'intervallo disponibile in quella subnet.

    • Le entità IAM che supervisionano l'intero servizio web sono amministratori di progetto in entrambi i progetti di servizio e hanno autorizzazioni a livello di progetto per il progetto host in modo che possano utilizzare qualsiasi subnet definita.

    • Facoltativamente, un amministratore del VPC condiviso può delegare le attività di amministrazione della rete agli amministratori della rete e della sicurezza.

Passaggi successivi