VPC condiviso

Questa pagina fornisce una panoramica del VPC condiviso in Google Cloud. Un VPC condiviso consente a un'organizzazione di connettere risorse di più progetti a una rete Virtual Private Cloud (VPC) comune, in modo da comunicare tra loro in modo sicuro ed efficiente utilizzando indirizzi IP interni di quella rete.

Quando utilizzi un VPC condiviso, designi un progetto come progetto host a cui colleghi uno o più altri progetti di servizio. Le reti VPC nel progetto host sono chiamate reti VPC condivise. Le risorse idonee dei progetti di servizio possono utilizzare subnet nella rete VPC condiviso.

Un VPC condiviso consente agli amministratori dell'organizzazione di delegare le responsabilità amministrative, ad esempio per la creazione e la 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:

  • Implementa una best practice di sicurezza del privilegio minimo per l'amministrazione della rete, l'auditing e controllo dell'accesso. Gli amministratori del VPC condiviso possono delegare le attività di amministrazione di rete agli amministratori di rete e della sicurezza nella rete VPC condivisa senza consentire agli amministratori dei progetti di servizio di apportare modifiche che incidono sulla rete. Gli amministratori dei progetti di servizio possono solo creare e gestire istanze che utilizzano la rete VPC condiviso. Per ulteriori dettagli, consulta la sezione amministratori e IAM.
  • Applica e applica 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 le istanze che utilizzano subnet approvate nel progetto host del VPC condiviso.
  • Utilizza i progetti di servizio per separare i centri di budget o i centri di costo interni. Per ulteriori dettagli, consulta la sezione relativa alla billing.

Concetti

Organizzazioni, cartelle e progetti

Un VPC condiviso connette i progetti all'interno della stessa organizzazione. I progetti collegati possono trovarsi nella stessa o in cartelle diverse; tuttavia, se si trovano in cartelle diverse, l'amministratore deve disporre dei diritti di 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 è durante 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 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 VPC condiviso deve prima enable un progetto come progetto host. Successivamente, un amministratore VPC condiviso può collegare uno o più progetti di servizio.

  • Un progetto di servizio è qualsiasi progetto collegato a un progetto host da un amministratore VPC condiviso. Questo collegamento consente di partecipare al VPC condiviso. È prassi comune avere più progetti di servizio gestiti e amministrati da reparti o team diversi dell'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, tuttavia ogni progetto di servizio può essere associato a un solo progetto host. Per l'illustrazione, vedi l'esempio di più progetti host.

  • Puoi creare reti, subnet, intervalli di indirizzi secondari, regole firewall e altre risorse di rete nel progetto host. Il progetto host può quindi condividere subnet selezionate, compresi 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 è definito progetto autonomo. Questo sottolinea che non si tratta di un progetto host né di un progetto di servizio.

Una rete VPC autonoma è una rete VPC non condivisa che esiste 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 condiviso possono essere in modalità automatica o personalizzata, ma le reti legacy non sono supportate.

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

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

I progetti host e di servizio sono connessi tramite collegamenti a livello di progetto. Le subnet delle reti VPC condiviso 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 funzionano insieme per fornire diversi livelli di controllo dell'accesso dell'accesso. I criteri dell'organizzazione consentono di impostare controlli a livello di organizzazione, cartella o progetto.

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

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

  • Puoi specificare le subnet VPC condiviso 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 interessa le risorse esistenti. Le risorse esistenti continuano a funzionare normalmente nelle rispettive subnet anche se un criterio impedisce l'aggiunta di nuove risorse. Per ulteriori informazioni, consulta il vincolo constraints/compute.restrictSharedVpcSubnetworks.

Amministratori e IAM

Il VPC condiviso utilizza i ruoli IAM (Identity and Access Management) per l'amministrazione con delega. I seguenti ruoli possono essere concessi alle entità IAM, ad esempio utenti, gruppi Google, domini Google o account di servizio Google Cloud. Se devi contattare uno di questi amministratori, puoi cercarli nei criteri 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) Finalità
Amministratore dell'organizzazione (resourcemanager.organizationAdmin)
• Entità IAM nell'organizzazione
Gli amministratori dell'organizzazione hanno il ruolo resourcemanager.organizationAdmin per la tua organizzazione. Nominano gli amministratori del VPC condiviso concedendo loro i ruoli appropriati per la creazione e l'eliminazione dei progetti e il ruolo Amministratore VPC condiviso per l'organizzazione. Questi amministratori possono definire criteri a livello di organizzazione, ma azioni specifiche per cartelle e progetti richiedono ruoli aggiuntivi per cartelle e progetti.
Amministratore VPC condiviso
(compute.xpnAdmin e
resourcemanager.projectIamAdmin)
• Entità IAM nell'organizzazione o
• Entità IAM in una cartella
Gli amministratori del VPC condiviso hanno i ruoli Amministratore VPC condiviso Compute (compute.xpnAdmin) e Amministratore IAM progetto (resourcemanager.projectIamAdmin) per l'organizzazione o per una o più cartelle. Esegue le varie attività necessarie per configurare il VPC condiviso, ad esempio 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 agli amministratori dei progetti di servizio. Un amministratore VPC condiviso per un determinato progetto host è in genere anche il proprietario del progetto.
Un utente a cui è stato assegnato il ruolo Amministratore VPC condiviso Compute per l'organizzazione ha questo ruolo per tutte le cartelle dell'organizzazione. Un utente assegnato al ruolo per una cartella ha questo ruolo per la cartella specificata e per le cartelle nidificate al di sotto. Un amministratore VPC condiviso può collegare i progetti in due cartelle diverse solo se l'amministratore ha il ruolo per entrambe le cartelle.
Amministratore del progetto di servizio
(compute.networkUser)
• Entità IAM nell'organizzazione oppure
• Entità IAM in un progetto host oppure
• Entità IAM in alcune subnet nel progetto host
Un amministratore VPC condiviso definisce un amministratore del progetto di servizio concedendo a un'entità IAM il ruolo Utente di rete (compute.networkUser) all'intero progetto host o a selezionare 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, per cui devono disporre del ruolo Amministratore istanze (compute.instanceAdmin) per i progetti di servizio corrispondenti. Possono avere ruoli IAM aggiuntivi per i progetti di servizio, ad esempio il proprietario del progetto.

Amministratori progetti di servizio

Quando definisci 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 in modo che disponga dell'autorizzazione per utilizzare tutte le subnet nel progetto host se l'amministratore del VPC condiviso concede all'amministratore del progetto di servizio il ruolo compute.networkUser per l'intero progetto host. Il risultato è che l'amministratore del progetto di servizio è autorizzato a utilizzare tutte le subnet in 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 del 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 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 quelle subnet. Dopo aver aggiunto nuove reti VPC condivise o nuove subnet al progetto host, un amministratore VPC condiviso deve esaminare le associazioni di autorizzazioni per il ruolo compute.networkUser per garantire che le autorizzazioni a livello di subnet per tutti gli amministratori di progetti di servizio corrispondano alla configurazione prevista.

Amministratori di rete e sicurezza

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

Amministratore Finalità
Amministratore di rete
• Entità IAM nel progetto host oppure
• Entità IAM nell'organizzazione
L'amministratore VPC condiviso definisce un amministratore di rete concedendo a un'entità IAM il ruolo Amministratore 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 sicurezza
• Entità IAM nel progetto host oppure
• Entità IAM nell'organizzazione
Un amministratore VPC condiviso può definire un amministratore della 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 di VPC condiviso sono soggetti a quote VPC standard per progetto. Le reti VPC condiviso 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 il VPC condiviso.

Fatturazione

La fatturazione per le risorse che partecipano a una rete VPC condiviso viene attribuita al progetto di servizio in cui si trova la risorsa, anche se la risorsa utilizza la rete VPC condiviso 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 condiviso sono le stesse utilizzate se le risorse si trovassero nel progetto host stesso.
  • La fatturazione per il traffico in uscita generato da una risorsa viene attribuita al progetto in cui la risorsa è definita:
    • Il traffico in uscita da un'istanza viene attribuito al progetto che contiene l'istanza. Ad esempio, se un'istanza viene creata in un progetto di servizio, ma utilizza una rete VPC condiviso, qualsiasi fatturazione per il traffico in uscita che genera viene attribuita al suo progetto di servizio. In questo modo, puoi utilizzare il VPC condiviso per organizzare le risorse in centri di costo della tua organizzazione.
    • I costi associati a un bilanciatore del carico vengono addebitati al progetto che contiene i componenti del bilanciatore del carico. Per ulteriori dettagli sul bilanciamento del carico e sul VPC condiviso, consulta la sezione sul bilanciamento del carico.
    • Il traffico in uscita verso le VPN viene attribuito al progetto contenente la risorsa gateway VPN. Ad esempio, se nella rete VPC condiviso viene creato un gateway VPN, sarà incluso nel progetto host. Il traffico in uscita attraverso il gateway VPN, indipendentemente dal progetto di servizio che avvia il trasferimento dei dati in uscita, viene attribuito al progetto host.
    • I costi per il traffico proveniente da una risorsa in un progetto di servizio VPC condiviso che vengono trasferiti attraverso un collegamento VLAN vengono attribuiti al progetto proprietario del collegamento VLAN. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.

Risorse

Risorse idonee

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

Le seguenti limitazioni si applicano alle risorse idonee per la partecipazione a uno scenario di VPC condiviso:

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

  • Alcune risorse devono essere ricreate per utilizzare una rete VPC condiviso Quando un amministratore VPC condiviso collega un progetto esistente a un progetto host, quel progetto diventa un progetto di servizio, ma le risorse esistenti non utilizzano automaticamente le risorse di rete condivise. Per utilizzare una rete VPC condiviso, un amministratore del progetto di servizio deve creare una risorsa idonea e configurarla in modo da utilizzare una subnet di una rete VPC condiviso. Ad esempio, un'istanza esistente in un progetto di servizio non può essere riconfigurata per l'utilizzo di una rete VPC condiviso, ma è possibile creare una nuova istanza per utilizzare le subnet disponibili in una rete VPC condiviso. Questo limite 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 Creare un'istanza.

Le istanze nei progetti di servizio collegati a un progetto host che utilizza la stessa rete VPC condiviso possono comunicare tra loro internamente utilizzando i relativi indirizzi IPv4 interni o gli indirizzi IPv6 interni o esterni, in conformità alle regole firewall applicabili.

Gli amministratori dei progetti di servizio possono assegnare uno qualsiasi dei seguenti tipi di indirizzo IP alle risorse in un progetto di servizio:

  • Indirizzi IPv4 e IPv6 temporanei: un indirizzo IP temporaneo può essere assegnato automaticamente a un'istanza in un progetto di servizio. Ad esempio, quando gli amministratori dei progetti di servizio creano istanze, selezionano la rete VPC condiviso e una subnet condivisa disponibile. L'indirizzo IPv4 interno principale dell'istanza proviene dall'intervallo di indirizzi IP disponibili nell'intervallo di indirizzi IPv4 principali della subnet condivisa selezionata. Se configura l'istanza come istanza a doppio stack, l'indirizzo IPv6 dell'istanza proviene dall'intervallo di indirizzi IP disponibili nell'intervallo di subnet IPv6 della subnet condivisa selezionata.

    Gli indirizzi IPv4 temporanei possono essere assegnati automaticamente anche ai bilanciatori del carico interni. Per ulteriori informazioni, consulta la sezione Creare un bilanciatore del carico di rete passthrough interno o Creare un bilanciatore del carico delle applicazioni interno.

  • Indirizzi IPv4 e IPv6 interni statici: un indirizzo IPv4 o IPv6 interno statico può essere prenotato in un progetto di servizio. L'oggetto con indirizzo IPv4 o IPv6 interno deve essere creato nello stesso progetto di servizio della risorsa che lo utilizza, anche se il valore dell'indirizzo IP proviene dagli indirizzi IP disponibili della subnet condivisa selezionata in una rete VPC condiviso. Per ulteriori informazioni, consulta Prenotare indirizzi IP4 e IPv6 interni statici nella pagina "Provisioning del VPC condiviso".

  • Indirizzi IPv4 esterni statici: gli oggetti indirizzo IPv4 esterni definiti nel progetto host possono essere utilizzati dalle risorse sia nel progetto host sia in qualsiasi progetto di servizio collegato. I progetti di servizio possono anche usare i propri oggetti indirizzo IPv4 esterni. Ad esempio, un'istanza in un progetto di servizio può utilizzare un indirizzo IPv4 esterno a livello di regione definito nel progetto di servizio o nel progetto host.

  • Indirizzi IPv6 esterni statici:un amministratore del progetto di servizio può anche scegliere di prenotare un indirizzo IPv6 esterno statico. L'oggetto dell'indirizzo IPv6 esterno deve essere creato nello stesso progetto di servizio della risorsa che lo utilizza, anche se il valore dell'indirizzo IP proviene dagli indirizzi IPv6 disponibili della subnet condivisa selezionata in una rete VPC condiviso. Per ulteriori informazioni, consulta Prenotare un indirizzo IPv6 esterno statico nella pagina Provisioning del VPC condiviso.

DNS interno

Le VM nello stesso progetto di servizio possono raggiungersi utilizzando i nomi DNS interni creati automaticamente da Google Cloud. Questi nomi DNS utilizzano l'ID del progetto di servizio in cui vengono create le VM, anche se i nomi puntano a indirizzi IP interni nel progetto host. Per una spiegazione completa, consulta Nomi DNS interni e VPC condiviso nella documentazione relativa al DNS interno.

Zone private di Cloud DNS

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

Bilanciamento del carico

Il VPC condiviso può essere utilizzato in combinazione con Cloud Load Balancing. Nella maggior parte dei casi, le istanze di backend in un progetto di servizio vengono create. In questo caso, tutti i componenti del bilanciatore del carico vengono creati in quel progetto. Sebbene sia possibile creare istanze di backend nel progetto host, una configurazione di questo tipo non è adatta per i tipici deployment di VPC condiviso, poiché non separa le responsabilità di amministrazione della rete e sviluppo dei servizi.

Utilizza i link nella tabella seguente per scoprire di più sulle architetture di VPC condiviso supportate per ciascun tipo di bilanciatore del carico.

Tipo di bilanciatore del carico Link
Bilanciatore del carico delle applicazioni esterno Architettura di un VPC condiviso
Bilanciatore del carico delle applicazioni interno Architettura di un VPC condiviso
Bilanciatore del carico di rete proxy esterno Architettura di un VPC condiviso
Bilanciatore del carico di rete proxy interno Architettura di un VPC condiviso
Bilanciatore del carico di rete passthrough interno Architettura di un VPC condiviso
Bilanciatore del carico di rete passthrough esterno Architettura di un VPC condiviso

Esempi e casi d'uso

Concetti di base

La Figura 1 illustra un semplice scenario di VPC condiviso:

Figura 1. Un progetto host con una rete VPC condivisa fornisce connettività interna per due progetti di servizio, mentre un progetto autonomo non utilizza un VPC condiviso (fai clic per ingrandire).
  • Un amministratore VPC condiviso dell'organizzazione ha creato un progetto host a cui è 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 dei progetti di servizio con almeno autorizzazioni a livello di subnet per 10.0.1.0/24 subnet ha creato Instance A in una zona della regione us-west1. Questa istanza riceve il proprio 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 dei progetti di servizio con almeno autorizzazioni a livello di subnet per 10.15.2.0/24 subnet ha creato Instance B in una zona della regione us-east1. Questa istanza riceve il proprio indirizzo IP interno, 10.15.2.4, dal blocco CIDR 10.15.2.0/24.

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

Più progetti host

La Figura 2 mostra come utilizzare il VPC condiviso per creare ambienti di test e produzione separati. Per questo caso, un'organizzazione ha deciso di utilizzare due progetti host distinti, un ambiente di test e un ambiente di produzione.

Figura 2. Un progetto host dell'ambiente di test e un progetto host dell'ambiente di produzione utilizzano il VPC condiviso per creare ambienti di produzione e di test distinti (fai clic per ingrandire).
  • Un amministratore VPC condiviso per l'organizzazione ha creato due progetti host e ha collegato due progetti di servizio come segue:

    • I progetti di servizio Apps testing e Mobile testing sono collegati al progetto host Test environment. Gli amministratori dei progetti di servizio di 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 di 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 condiviso con subnet configurate in modo da utilizzare gli stessi intervalli CIDR. In Testing network e in Production network, le due subnet sono:

    • 10.0.1.0/24 subnet nella regione us-west1

    • 10.15.2.0/24 subnet nella regione 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 simili a quelle che dispongono delle autorizzazioni a livello di subnet almeno per 10.0.1.0/24 subnet.

    • Nota che entrambe le istanze utilizzano l'indirizzo IP 10.0.1.3. Questo è accettabile perché ogni istanza esiste in un progetto di servizio associato a un progetto host univoco contenente la propria rete VPC condiviso. Entrambe le reti di test e di produzione sono state volutamente configurate nello stesso modo.

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

Scenario cloud ibrido

La Figura 3 mostra come utilizzare il VPC condiviso in un ambiente ibrido.

Figura 3. Una rete VPC condiviso è connessa a una rete on-premise e a tre progetti di servizio (fai clic per ingrandire).

In questo esempio, un'organizzazione ha creato un singolo progetto host con una singola rete VPC condiviso. La rete VPC condivisa viene 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 VPC condiviso ha abilitato il progetto host e vi ha collegato tre progetti di servizio: Service project A, Service project B e Service project C.

    • Team separati possono gestire ogni progetto di servizio. Le autorizzazioni IAM sono state configurate in modo che un amministratore dei progetti di servizio per un progetto non disponga di autorizzazioni per gli altri progetti di servizio.

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

      • Un amministratore del progetto di servizio per Service project A con 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 è la regione 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 con autorizzazioni a livello di subnet per 10.15.2.0/24 subnet può creare Instance B al suo interno. L'amministratore del progetto di servizio deve scegliere una zona nell'area geografica us-east1 per l'istanza, perché questa è la regione 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 del progetto di servizio per Service project C con autorizzazioni a livello di progetto per l'intero progetto host può creare istanze in qualsiasi subnet in qualsiasi rete VPC nel progetto host. Ad esempio, l'amministratore del progetto di servizio può creare Instance C in 10.7.1.0/24 subnet, scegliendo una zona nella regione us-east1 che corrisponda a quella della 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 di ogni progetto sono responsabili della creazione e gestione delle risorse.

  • Un amministratore VPC condiviso ha delegato le attività di amministrazione di rete ad altre entità IAM che sono amministratori di 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 su 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 regione us-east1.

    • 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 sua 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, ad esempio server di database o directory on-premise.

Servizio web a due livelli

La Figura 4 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 team diversi gestiscono ogni livello. Il livello 1 rappresenta il componente rivolto all'esterno, dietro un bilanciatore del carico HTTP(S). Il livello 2 rappresenta un servizio interno su cui fa riferimento il livello 1 e viene bilanciato mediante un bilanciatore del carico TCP/UDP interno.

Figura 4. In questo servizio web a due livelli, un componente rivolto all'esterno e un servizio interno sono connessi a una rete VPC condiviso comune e gestiti da team diversi (fai clic per ingrandire).

Il VPC condiviso consente di mappare ogni livello del servizio web a progetti diversi, in modo che possano essere gestiti da team diversi condividendo una rete VPC comune:

  • Le risorse, come istanze e componenti del bilanciatore del carico, per ogni livello vengono inserite in singoli progetti di servizio gestiti da team diversi.

  • Ogni progetto di servizio di livello è stato collegato al progetto host da un amministratore VPC condiviso. L'amministratore del VPC condiviso ha anche 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 di ogni progetto sono responsabili della creazione e gestione delle risorse.

  • Controllo dell'accesso alla rete è definito come segue:

    • Le entità IAM che lavorano solo nel livello 1 sono amministratori dei progetti di servizio per Tier 1 service project e hanno autorizzazioni a livello di subnet solo per 10.0.1.0/24 subnet. In questo esempio, uno di questi amministratori progetto di servizio ha creato tre Tier 1 instances in quella subnet.

    • Le entità IAM che lavorano solo nel livello 2 sono amministratori del progetto di servizio per Tier 2 service project e hanno autorizzazioni a livello di subnet solo per 10.0.2.0/24 subnet. In questo esempio, un altro amministratore di progetti 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 dei progetti di servizio in entrambi i progetti di servizio e dispongono di autorizzazioni a livello di progetto per il progetto host in modo da poter utilizzare qualsiasi subnet definita al suo interno.

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

Passaggi successivi