VPC condiviso

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

Quando utilizzi un VPC condiviso, designi un progetto come progetto host, allegando uno o più progetti di servizio. Le reti VPC nel progetto host sono chiamate Reti VPC condivise. Idoneo dai progetti di servizio possono utilizzare subnet della rete VPC condiviso.

Il VPC condiviso consente a organizzazione Google Workspace delegare le responsabilità amministrative, ad esempio creare e gestire alle istanze di servizio, agli amministratori dei progetti di servizio mantenendo un controllo centralizzato delle risorse di rete come subnet, route e firewall. Questo modello permette alle organizzazioni di:

  • Implementare una best practice di sicurezza del privilegio minimo per la rete amministrazione, controllo e controllo dell'accesso. Gli amministratori della rete VPC condivisa possono delegare attività di amministrazione di rete agli amministratori di rete e della sicurezza nella VPC condiviso senza consentire agli amministratori dei progetti di servizio di influire sulla rete modifiche. Agli amministratori dei progetti di servizio viene data solo la possibilità di creare per gestire le istanze che utilizzano la rete VPC condiviso. Consulta le amministratori e IAM per maggiori dettagli.
  • Applicare e imporre criteri di controllo dell'accesso coerenti a livello di rete per più progetti di servizio nell'organizzazione mentre delega le richieste amministrative e le responsabilità aziendali. Ad esempio, gli amministratori dei progetti di servizio possono Essere amministratori di istanze Compute del proprio progetto, creando ed eliminando le istanze che usano subnet approvate nel progetto host del VPC condiviso.
  • Utilizzare i progetti di servizio per separare la definizione del budget o i centri di costo interni. Consulta consulta la sezione Fatturazione per ulteriori dettagli.
di Gemini Advanced.

Concetti

Organizzazioni, cartelle e progetti

Un VPC condiviso connette i progetti all'interno dello stesso organizzazione. I progetti collegati possono essere nello stesso luogo o in uno diverso cartelle, ma se si trovano in cartelle diverse l'amministratore deve avere Diritti di amministratore VPC condiviso per entrambe le cartelle. Invita alla risorsa Google Cloud per per saperne di più su organizzazioni, cartelle e progetti.

I progetti host e di servizio partecipanti non possono appartenere a nessuno le tue organizzazioni. L'unica eccezione è quando la migrazione dei progetti da un'organizzazione all'altra. Durante la migrazione, i progetti di servizio possono fare parte di un'organizzazione diversa da quella del progetto host. Per ulteriori informazioni informazioni sulla migrazione dei progetti, consulta Migrazione Google Cloud.

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

  • Un progetto host contiene uno o più VPC condivisi reti. Un amministratore della rete VPC condivisa deve abilita innanzitutto un progetto come progetto host. In seguito, un amministratore della rete VPC condivisa può collegare a cui colleghi uno o più progetti di servizio.

  • Un progetto di servizio è qualsiasi progetto che è stato collegato a un progetto host da un Amministratore VPC condiviso. Questo collegamento gli consente di partecipare al VPC condiviso. È una pratica comune per far gestire e amministrare più progetti di servizio da reparti o team diversi della tua organizzazione.

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

  • Puoi creare e utilizzare più progetti host; ma ogni progetto di servizio può essere collegato a un solo progetto host. Per un'illustrazione, consulta la sezione 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 condividi subnet selezionate, inclusi intervalli secondari, con dei progetti di servizio. I servizi in esecuzione in un progetto di servizio possono utilizzare Un VPC condiviso per comunicare con le risorse in esecuzione nell'altro dei progetti di servizio.

Per chiarezza, un progetto che non partecipa a un VPC condiviso è chiamato in un progetto autonomo. Ciò sottolinea che non si tratta né di un progetto host di 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 centralmente idoneo di assistenza nei progetti di servizio. Le reti VPC condiviso possono essere automatiche o personalizzate predefinita, ma legacy di rete non sono supportate.

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

  • Puoi condividere tutte le subnet del progetto host. Se selezioni questa opzione, a tutte le nuove subnet create nel progetto host, incluse le subnet verranno condivise anche altre reti.
  • Puoi specificare singole subnet da condividere. Se condividi subnet singolarmente, vengono condivise solo quelle subnet, a meno che non modifichi manualmente dall'elenco.

I progetti host e di servizio sono collegati da collegamenti a livello di progetto. Le subnet delle reti VPC condiviso nel progetto host sono accessibili dal 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. I criteri dell'organizzazione ti consentono per impostare i controlli a livello di organizzazione, cartella o progetto.

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

  • Puoi limitare l'insieme di progetti host a cui un progetto non host o un progetto non host puoi collegare i progetti in una cartella o un'organizzazione. Il vincolo si applica quando un amministratore della rete VPC condivisa collega un progetto di servizio a un progetto host. Il vincolo non influisce sugli allegati esistenti. Gli allegati esistenti rimangono intatti anche se un criterio ne rifiuta di nuovi. Per ulteriori informazioni informazioni, consulta constraints/compute.restrictSharedVpcHostProject di blocco.

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

Amministratori e IAM

Il VPC condiviso utilizza Identity and Access Management (IAM) per l'amministrazione delegata. Le seguenti i ruoli possono essere concessi a IAM come utenti, entità di Google gruppi, domini Google o account di servizio Google Cloud. Se hai bisogno per contattare uno di questi amministratori, puoi cercarlo nel criterio IAM del progetto. Se non disponi di autorizzazioni necessarie, devi contattare un amministratore di rete o dell'organizzazione.

Ruoli amministrativi richiesti

Amministratore (ruolo IAM) Finalità
Amministratore dell'organizzazione (resourcemanager.organizationAdmin)
• Entità IAM nell'organizzazione		 Gli amministratori dell'organizzazione hanno Ruolo resourcemanager.organizationAdmin per la tua organizzazione. Nominano Amministratori del VPC condiviso concedendo loro appropriata i ruoli di creazione ed eliminazione dei progetti e Amministratore VPC condiviso per l'organizzazione. Questi amministratori possono definire a livello di organizzazione ma specifiche azioni per cartelle e progetti richiedono nei ruoli di cartella e progetto.
Amministratore VPC condiviso
(compute.xpnAdmin e
resourcemanager.projectIamAdmin)
• Entità IAM nell'organizzazione oppure
• Entità IAM in una cartella		 Gli amministratori della rete VPC condivisa Amministratore VPC condiviso Compute (compute.xpnAdmin) e Amministratore IAM progetto (resourcemanager.projectIamAdmin) ruoli per all'organizzazione o a una o più cartelle. Svolgono varie attività necessario per configurare un VPC condiviso, come l'abilitazione dei progetti host, il collegamento a ospitare progetti e delegare l'accesso ad alcune o a tutte in reti VPC condiviso agli amministratori dei progetti di servizio. Un VPC condiviso L'amministratore di 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 quel ruolo per tutte le cartelle dell'organizzazione. Un utente a cui è stato assegnato il ruolo per una cartella ha quel ruolo per la cartella specificata e per eventuali cartelle nidificate sottostante. Un amministratore della rete VPC condivisa può collegare progetti in due solo se l'amministratore ha il ruolo per entrambe le cartelle.
Amministratore progetti 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 della rete VPC condivisa definisce un amministratore del progetto di servizio concedendo un IAM l'entità il ruolo Utente di rete (compute.networkUser) per l'intero progetto host oppure le subnet selezionate delle sue VPC condiviso condivise. Gli amministratori dei progetti di servizio gestiscono anche la proprietà e il controllo delle risorse definite nei progetti di servizio, dovrebbe avere Ruolo di Amministratore istanze (compute.instanceAdmin) per ai progetti di servizio corrispondenti. Può avere ruoli IAM aggiuntivi ai progetti di servizio, ad esempio il proprietario del progetto.

Amministratori progetti di servizio

Durante la definizione di ogni amministratore del progetto di servizio, un amministratore della rete VPC condivisa può concedere per utilizzare l'intero progetto host o solo alcune subnet:

  • Autorizzazioni a livello di progetto: un amministratore progetto di servizio può essere definito in modo che per l'utilizzo di tutte le app subnet nell'host progetto se l'amministratore della rete VPC condivisa 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 dispone dell'autorizzazione per utilizzare tutte le subnet in tutte le reti VPC di al progetto host, incluse le subnet e le reti VPC aggiunte al progetto host. in futuro.

  • Autorizzazioni a livello di subnet: in alternativa, un amministratore del progetto di servizio può a un insieme più restrittivo di autorizzazioni a utilizzare alle subnet se l'Amministratore del VPC condiviso concede il ruolo di compute.networkUser per le subnet selezionate al Amministratore progetto di servizio. Un amministratore progetti di servizio con accesso solo a livello di subnet autorizzazioni limitate all'uso esclusivo di quelle subnet. Dopo il nuovo VPC condiviso di rete o di nuove subnet al progetto host, un amministratore del VPC condiviso deve esaminare le associazioni di autorizzazioni per il ruolo compute.networkUser per assicurati che le autorizzazioni a livello di subnet per tutti gli amministratori dei progetti di servizio corrispondano la 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 condiviso. Facoltativamente, possono delegare alcune 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 della rete VPC condivisa definisce un amministratore di rete concedendo un ruolo IAM l'entità Amministratore rete (compute.networkAdmin) al ruolo progetto host. Gli amministratori di rete hanno il controllo completo su tutte le risorse di rete tranne che per le regole firewall e i certificati SSL.
Amministratore sicurezza
• Entità IAM nel progetto host oppure
• Entità IAM nell'organizzazione		 Un amministratore della rete VPC condivisa può definire un Amministratore sicurezza concedendo un ruolo IAM l'entità Ruolo Amministratore sicurezza (compute.securityAdmin) per del progetto host. Gli amministratori della sicurezza gestiscono le regole firewall e SSL certificati.

Specifiche

Quote e limiti

I progetti host del VPC condiviso sono soggetti allo standard per progetto Quote VPC. VPC condiviso sono soggetti ai limiti per rete e limiti per istanza per VPC reti. Inoltre, le relazioni tra progetti host e progetti di servizio è regolato da limiti specifici del VPC condiviso.

Fatturazione

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

  • Tariffe e regole utilizzate per calcolare gli importi di fatturazione per le risorse nei progetti di servizio che utilizzano una rete VPC condiviso è uguale a le risorse si trovavano nel progetto host.
  • La fatturazione del traffico in uscita generato da una risorsa viene attribuita al progetto in cui è definita la risorsa:
    • Il traffico in uscita proveniente 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 viene attribuita al progetto di servizio. In questo modo è possibile utilizzare VPC condiviso per organizzare le risorse in centri di costo per la tua organizzazione.
    • Vengono addebitati i costi associati a un bilanciatore del carico al progetto contenente i componenti del bilanciatore del carico. Per maggiori dettagli sul bilanciamento del carico e sul VPC condiviso, consulta Informazioni sul bilanciamento del carico .
    • Il traffico in uscita verso le VPN viene attribuito al progetto contenente la VPN Risorsa gateway. Ad esempio, se un gateway VPN viene creato nella Rete VPC condiviso, è contenuta nel progetto host. In uscita traffico attraverso il gateway VPN, indipendentemente dal servizio avvia il trasferimento di dati in uscita; viene attribuito al progetto host.
    • Costi per il traffico da una risorsa in un progetto di servizio del VPC condiviso che vengono trasferiti in uscita attraverso un collegamento VLAN vengono attribuiti al progetto è proprietario del collegamento VLAN. Per ulteriori informazioni, consulta Cloud Interconnect prezzi.

Risorse

Risorse idonee

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

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

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

  • Alcune risorse devono essere ricreate per utilizzare una rete VPC condiviso Quando un amministratore della rete VPC condivisa collega un progetto esistente a un progetto, diventa un progetto di servizio, ma le sue risorse esistenti non usano automaticamente delle tue risorse di rete. Per utilizzare una rete VPC condiviso, un amministratore del progetto di servizio deve crea una risorsa idonea e configurala per utilizzare una subnet di un VPC condiviso in ogni rete. Ad esempio, un'istanza esistente in un progetto di servizio non può essere riconfigurata per utilizzare una rete VPC condiviso, ma è possibile creare una nuova istanza possono utilizzare le subnet disponibili in una rete VPC condiviso. Questo limite si applica a in zone private.

Indirizzi IP

Quando crei un'istanza in un progetto di servizio, puoi configurarla come un'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, vedi Crea un'istanza.

Istanze nei progetti di servizio collegati a un progetto host che utilizza lo stesso La rete VPC condiviso può comunicare internamente tra loro utilizzando indirizzi IPv4 interni o relativi indirizzi IPv6 interni o esterni, alle regole firewall applicabili.

Gli amministratori dei progetti di servizio possono assegnare uno qualsiasi dei seguenti tipi di indirizzi IP a in un progetto di servizio:

  • Indirizzi IPv4 e IPv6 temporanei:un indirizzo IP temporaneo può essere assegnati automaticamente a un'istanza in un progetto di servizio. Ad esempio, quando gli amministratori progetti di servizio creano di Compute Engine, seleziona la rete VPC condiviso e una rete VPC subnet. La l'indirizzo IPv4 interno principale dell'istanza proviene dall'intervallo di indirizzi IP disponibili nell'intervallo di indirizzi IPv4 principale della subnet condivisa selezionata. Se configurare l'istanza come istanza a doppio stack, l'indirizzo IPv6 dell'istanza proviene dall'intervallo di indirizzi IP disponibili nelle subnet condivise Intervallo di subnet IPv6.

    Anche gli indirizzi IPv4 temporanei possono essere assegnati automaticamente al carico interno bilanciatori del carico e bilanciatori del carico. Per ulteriori informazioni, consulta la sezione sulla creazione di un bilanciatore del carico di rete passthrough interno oppure crea 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 dell'indirizzo IPv4 o IPv6 interno devono essere creati nello stesso progetto di servizio della risorsa che lo utilizza, anche sebbene il valore dell'indirizzo IP provenga dagli indirizzi IP disponibili alla subnet condivisa selezionata in una rete VPC condiviso. Per ulteriori informazioni, consulta Prenotare indirizzi IP4 e IPv6 interni statici in "Esegui il provisioning di un VPC condiviso" .

  • Indirizzi IPv4 esterni statici: oggetti di indirizzi IPv4 esterni definiti in il progetto host può essere utilizzato dalle risorse in quel progetto host in qualsiasi progetto di servizio collegato. I progetti di servizio possono anche utilizzare progetti Oggetti di indirizzi IPv4. Ad esempio, un'istanza in un progetto di servizio può utilizzare un indirizzo IPv4 esterno regionale definito nel progetto di servizio o del progetto host.

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

DNS interno

Le VM nello stesso progetto di servizio possono raggiungersi utilizzando il DNS interno che Google Cloud crea automaticamente. Questi nomi DNS utilizzano ID del progetto di servizio in cui vengono create le VM, anche se puntano a indirizzi IP interni nel progetto host. Per un spiegazione, vedi 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 tua zona privata nel progetto host e autorizzare l'accesso a la zona per la rete VPC condiviso o configurare la zona in un servizio utilizzando l'associazione tra progetti.

Bilanciamento del carico

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

Utilizza i link nella tabella seguente per scoprire di più sui modelli supportati Architetture VPC condiviso per ogni tipo di bilanciatore del carico.

Tipo di bilanciatore del carico Link
Bilanciatore del carico delle applicazioni esterno VPC condiviso condivisa
Bilanciatore del carico delle applicazioni interno VPC condiviso dell'architettura
Bilanciatore del carico di rete proxy esterno VPC condiviso dell'architettura
Bilanciatore del carico di rete proxy interno VPC condiviso dell'architettura
Bilanciatore del carico di rete passthrough interno VPC condiviso condivisa
Bilanciatore del carico di rete passthrough esterno VPC condiviso condivisa

Esempi e casi d'uso

Concetti di base

La figura 1 mostra uno scenario di VPC condiviso semplice:

Figura 1. Un progetto host con un La rete VPC condiviso fornisce connettività interna progetti di servizio, mentre un progetto autonomo non utilizza VPC condiviso (fai clic per ingrandire).

  • Un amministratore della rete VPC condivisa dell'organizzazione ha creato un progetto host. ha collegato due progetti di servizio:

    • È possibile configurare gli amministratori dei progetti di servizio in Service project A per accedere a tutte o solo ad alcune subnet nella rete VPC condiviso. Un progetto di servizio Amministratore con autorizzazioni almeno 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 CIDR 10.0.1.0/24 bloccare.

    • È possibile configurare gli amministratori dei progetti di servizio in Service project B per accedere a tutte o solo ad alcune subnet nella rete VPC condiviso. Un progetto di servizio Amministratore con autorizzazioni almeno 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, da 10.15.2.0/24 Blocco CIDR.

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

Più progetti host

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

Figura 2. un progetto host dell'ambiente di test e un progetto il progetto host dell'ambiente usa un VPC condiviso per creare ambienti di produzione e di test (fai clic per ingrandire).

  • Un amministratore della rete VPC condivisa dell'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 il progetto host Test environment. amministratori progetti di servizio in ogni può essere configurato per accedere a tutte o ad alcune subnet Testing network.

    • I progetti di servizio Apps production e Mobile production sono collegato al progetto host Production environment. Progetto di servizio Gli amministratori di ogni progetto possono essere configurati per accedere a tutti o ad alcuni subnet in Production network.

  • Entrambi i progetti host hanno una rete VPC condiviso con subnet configurate per utilizzare gli stessi intervalli CIDR. Sia in Testing network che 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

  • Prendi in considerazione 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 loro, a condizione che dispongano almeno 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. Questo è accettabile perché ogni istanza esiste in un progetto di servizio collegato in un progetto host univoco contenente la propria rete VPC condiviso. Entrambi i campi di test e produzione sono state configurate intenzionalmente in allo stesso modo.

    • Le istanze che utilizzano 10.0.1.0/24 subnet devono trovarsi in una zona in la stessa regione della subnet, anche se quest'ultima definiti in progetti separati. Poiché 10.0.1.0/24 subnet si trova nella regione us-west1, amministratori progetti di servizio che creano istanze utilizza quella subnet deve scegliere una zona nella stessa regione, come us-west1-a.

Scenario cloud ibrido

La figura 3 mostra come il VPC condiviso può essere utilizzato in un ambiente ibrido completamente gestito di Google Cloud.

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

In questo esempio, un'organizzazione ha creato un singolo host con una singola rete VPC condiviso. La rete VPC condivisa è connessa utilizzando Cloud VPN per una rete on-premise. Alcune applicazioni e servizi sono ospitati in Google Cloud, mentre altri sono mantenuti on-premise:

  • Un amministratore della rete VPC condivisa ha abilitato il progetto host e ha connesso progetti: Service project A, Service project B e Service project C.

    • Team separati possono gestire ciascuno dei progetti di servizio. Autorizzazioni IAM sono state configurate in modo tale che un amministratore del progetto di servizio di un progetto senza autorizzazioni per gli altri progetti di servizio.

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

      • Un amministratore progetti di servizio per Service project A con livello di subnet autorizzazioni per 10.0.1.0/24 subnet possono creare Instance A al suo interno. L'amministratore del progetto di servizio deve scegliere una zona nel us-west1 regione per l'istanza, perché è 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 progetti di servizio per Service project B con livello di subnet autorizzazioni per 10.15.2.0/24 subnet può creare Instance B in li annotino. L'amministratore del progetto di servizio deve scegliere una zona nel us-east1 regione per l'istanza, perché è 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 liberi in 10.15.2.0/24 subnet.

      • Un amministratore progetti di servizio per Service project C con livello di progetto autorizzazioni all'intero progetto host possono creare istanze in uno qualsiasi alle subnet in una qualsiasi delle reti VPC nel progetto host. Per Ad esempio, l'amministratore del progetto di servizio può creare Instance C 10.7.1.0/24 subnet, scegli una zona nella regione us-east1 per che corrisponda alla regione 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 del progetto di servizio di ogni progetto sono responsabili della creazione e la gestione delle risorse.

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

    • Un amministratore di rete ha creato un gateway Cloud VPN e configurato una VPN tramite internet a un gateway on-premise. Cloud VPN degli scambi e riceve route con la sua controparte on-premise perché il router Cloud corrispondente nella stessa regione us-east1 è stato configurato.

    • Se l'espressione dinamica di routing del VPC è globale, il router Cloud applica le route apprese ai server on-premise rete VPC in tutte le subnet della rete VPC e condivide le route 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 on-premise.

    • Soggetto alle regole firewall applicabili, alle istanze nei progetti di servizio può essere configurato per comunicare con servizi interni, come o server di directory situati on-premise.

Servizio web a due livelli

La Figura 4 mostra come si può utilizzare un VPC condiviso per delegare responsabilità amministrative e mantenere il principio del privilegio minimo. In questo caso, un'organizzazione ha un servizio web separato in due e team diversi gestiscono ogni livello. Il Livello 1 rappresenta rivolto all'esterno, dietro un caricamento HTTP(S) Google Cloud. Il livello 2 rappresenta un modello servizio su cui si basa il livello 1, ed è bilanciato mediante un TCP/UDP interno con il bilanciatore del carico di rete.

Figura 4. In questo servizio web a due livelli, rivolto verso l'alto e un servizio interno sono collegati a un Rete VPC condiviso e gestita da team diversi (fai clic per ingrandire).

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

  • Per ogni livello, risorse come istanze e componenti del bilanciatore del carico sono posizionati 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 della rete VPC condivisa ha abilitato anche il progetto host.

    • Team separati possono gestire ogni livello del servizio web grazie alla Amministratore progetti di servizio nel progetto di servizio appropriato.

    • Ogni progetto di servizio viene fatturato separatamente.

    • Gli amministratori del progetto di servizio di ogni progetto sono responsabili della creazione e la gestione delle risorse.

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

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

    • Le entità IAM che lavorano solo nel livello 2 sono amministratori progetti di servizio per Tier 2 service project e vengono concesse autorizzazioni a livello di subnet solo per 10.0.2.0/24 subnet. In questo esempio, un altro amministratore progetto di servizio ha creato tre Tier 2 instances in quella subnet, oltre a un la cui regola di forwarding utilizza un indirizzo IP dell'intervallo disponibili in quella subnet.

    • Le entità IAM che supervisionano l'intero servizio web sono amministratori progetti di servizio in entrambi i progetti di servizio e dispongono di autorizzazioni a livello di progetto per nel progetto host in modo da poter utilizzare qualsiasi subnet definita al suo interno.

    • Facoltativamente, un amministratore della rete VPC condivisa può delegare le attività di amministrazione della rete in Amministratori di rete e della sicurezza.

Passaggi successivi