Il pattern in uscita con accesso riservato e in entrata con accesso riservato utilizza una combinazione di traffico in uscita riservato e traffico in entrata riservato per scenari che richiedono un uso bidirezionale di API selezionate tra i carichi di lavoro. I carichi di lavoro possono essere eseguiti in Google Cloud, in modalità private on-premise o in altri ambienti cloud. In questo pattern, puoi usare l'API gateway, endpoint Private Service Connect o bilanciatori del carico esporre API specifiche e, facoltativamente, fornire autenticazione, autorizzazione Controlli delle chiamate API.
La principale distinzione tra questo pattern e motivo mesh sta nella sua applicazione a scenari che richiedono esclusivamente l'uso bidirezionale dell'API o comunicazione con origini e destinazioni di indirizzi IP specifici, ad esempio un'applicazione pubblicata mediante Private Service Connect endpoint. Poiché la comunicazione è limitato alle API esposte o agli indirizzi IP specifici, non è necessario che gli ambienti siano allineati nel progetto. Scenari comuni applicabili includono, a titolo esemplificativo:
- Fusioni e acquisizioni.
- Integrazioni di applicazioni con i partner.
- Integrazioni tra applicazioni e servizi di un'organizzazione con diverse unità organizzative che gestiscono le proprie applicazioni e ospitano in diversi ambienti.
La comunicazione funziona nel seguente modo:
- I carichi di lavoro di cui esegui il deployment in Google Cloud possono comunicare con il gateway API (o indirizzi IP di destinazione specifici) utilizzando indirizzi IP interni indirizzi IP esterni. Altri sistemi distribuiti nell'ambiente di calcolo privato non è raggiungibile.
- Al contrario, i carichi di lavoro di cui esegui il deployment in altri ambienti di computing può comunicare con il gateway API lato Google Cloud (o uno specifico l'indirizzo IP dell'endpoint pubblicato) utilizzando indirizzi IP interni. Altro di sistemi di cui è stato eseguito il deployment in Google Cloud.
Architettura
Il seguente diagramma mostra un'architettura di riferimento per il traffico in uscita con accesso riservato e pattern di traffico in entrata con accesso riservato:
L'approccio alla progettazione nel diagramma precedente comprende i seguenti elementi:
- Sul lato Google Cloud, esegui il deployment dei carichi di lavoro in un VPC VPC condiviso) senza esporli direttamente a internet.
- La rete dell'ambiente Google Cloud è estesa ad altre ambienti di computing. L'ambiente può essere on-premise o su un altro cloud. Per estendere l'ambiente, utilizza un modello Pattern di comunicazione per connettività ibrida e multi-cloud per facilitare la comunicazione tra gli ambienti in modo che possano utilizzare gli indirizzi IP interni.
- Facoltativamente, abilitando l'accesso a indirizzi IP di destinazione specifici, puoi
utilizza un VPC di transito per aggiungere un livello di sicurezza perimetrale al di fuori
VPC dell'applicazione.
- Puoi utilizzare il firewall di nuova generazione Cloud o le appliance virtuali di rete (NVA) con firewall di nuova generazione (NGFW) al VPC di transito verso esaminare il traffico e consentire o vietare l'accesso a determinate API da da origini specifiche prima di raggiungere il VPC dell'applicazione.
- Le API devono essere accessibili tramite un gateway API o un bilanciatore del carico forniscono un livello proxy e un'astrazione o un'interfaccia per le API di servizio.
- Per le applicazioni utilizzate come API, puoi anche Private Service Connect per fornire all'indirizzo IP interno dell'applicazione pubblicata.
- Tutti gli ambienti utilizzano uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.
Un'applicazione comune di questo pattern prevede il deployment dei backend delle applicazioni (o un sottoinsieme di backend di applicazioni) in Google Cloud durante l'hosting componenti backend e frontend in ambienti on-premise o in altri cloud (modello ibrido a più livelli o pattern multi-cloud partizionato). Man mano che le applicazioni si evolvono e migrano al cloud, le dipendenze spesso emergono preferenze specifiche per determinati servizi cloud.
A volte queste dipendenze e preferenze portano alla distribuzione di e backend tra diversi cloud provider. Inoltre, alcuni le applicazioni possono essere create con una combinazione di risorse e servizi distribuiti in ambienti on-premise e in più ambienti cloud.
Per le applicazioni distribuite, le funzionalità connettività ibrida e multi-cloud esterna di Cloud Load Balancing può essere utilizzato per terminare le richieste degli utenti e instradarle a frontend o backend in altri ambienti. Il routing avviene tramite una connessione di rete ibrida, illustrato nel seguente diagramma. Questa integrazione consente dei componenti dell'applicazione nei diversi ambienti. Richieste dal frontend ai servizi di backend ospitati in Google Cloud, in modo sicuro sulla connessione di rete ibrida stabilita, gestita da un bilanciatore del carico interno (ILB nel diagramma).
L'utilizzo del design di Google Cloud nel diagramma precedente consente di seguenti:
- Facilita la comunicazione bidirezionale tra Google Cloud, on-premise e in altri ambienti cloud che usano API predefinite che si allineano al modello comunicativo di questo modello.
- Per fornire frontend globali per le applicazioni per internet con componenti di applicazioni distribuiti (frontend o backend) e raggiungere i seguenti obiettivi, puoi utilizzare il metodo di caricamento funzionalità di bilanciamento e sicurezza di Google Cloud, punti di presenza (da un periodo all'altro):
- Riduci le spese in conto capitale e semplifica le operazioni utilizzando e senza server.
- Ottimizza la velocità delle connessioni ai backend delle applicazioni a livello globale
e latenza.
- Google Cloud Rete cross-cloud consente la comunicazione multi-cloud tra i componenti dell'applicazione connessioni private ottimali.
- Memorizza nella cache contenuti statici ad alta domanda e migliora l'applicazione e prestazioni elevate per le applicazioni che utilizzano Cloud Load Balancing globale fornendo l'accesso a Cloud CDN.
- Proteggi i frontend globali delle applicazioni per internet utilizzando le funzionalità di Google Cloud Armor che offrono distribuito a livello globale web application firewall (WAF) e i servizi di mitigazione degli attacchi DDoS.
- Facoltativamente, puoi incorporare Private Service Connect il tuo design. In questo modo, accesso privato e granulare alle API dei servizi Google Cloud o pubblicati da altri ambienti senza attraversare la rete internet pubblica.
Varianti
I pattern di architettura in uscita con accesso riservato e in entrata con accesso riservato possono essere combinati con altri approcci per soddisfare diversi requisiti di progettazione, pur prendendo in considerazione i requisiti di comunicazione di questo modello. I pattern offrono quanto segue: opzioni:
- Gateway API distribuiti
- Comunicazione bidirezionale dell'API mediante Private Service Connect
- Comunicazione bidirezionale utilizzando endpoint e interfacce Private Service Connect
Gateway API distribuiti
In scenari come quello basato pattern multi-cloud partizionato, (o componenti delle applicazioni) possono essere creati in ambienti on-premise, tra cui un ambiente on-premise privato. Il requisito comune è quello di instradare le richieste del client al frontend dell'applicazione direttamente in cui è ospitata l'applicazione (o il componente frontend). Questo tipo di comunicazione richiede un bilanciatore del carico locale o un gateway API. Queste applicazioni e i relativi componenti potrebbero richiedere anche una piattaforma API specifica di integrazione.
Il seguente diagramma illustra il modo in cui Apigee e Apigee ibrido sono progettate per soddisfare tali requisiti con un gateway API localizzato completamente gestito di Google Cloud. La gestione della piattaforma API è centralizzata in Google Cloud. Questo il design aiuta ad applicare rigide misure di controllo dell'accesso laddove gli indirizzi IP (API di destinazione e destinazione o (indirizzi IP endpoint Private Service Connect) possono comunicare tra Google Cloud e gli altri ambienti.
Il seguente elenco descrive i due distinti percorsi di comunicazione nel diagramma precedente che utilizzano Apigee Gateway API:
- Le richieste del client arrivano al frontend dell'applicazione direttamente che ospita l'applicazione (o il componente frontend).
- I gateway e i proxy API all'interno di ciascun ambiente gestiscono client e
richieste API delle applicazioni in diverse direzioni su più
ambienti cloud-native.
- Funzionalità gateway API in Google Cloud (Apigee) espone l'applicazione (frontend o backend) ospitati in Google Cloud.
- La funzionalità gateway API in un altro ambiente (ibrido) espone il frontend dell'applicazione (o backend) ospitati in quell'ambiente.
Facoltativamente, puoi considerare l'utilizzo di un VPC di transito. Un VPC di transito può fornire flessibilità per separare i problemi ed eseguire controlli di sicurezza e la connettività in una rete VPC separata. Da un indirizzo IP un VPC di transito (in cui è collegata la connettività ibrida) per mantenere la connettività end-to-end, soddisfa i seguenti requisiti:
- Gli indirizzi IP per le API di destinazione devono essere pubblicizzati all'altro in cui sono ospitati clienti/richiedenti.
- Gli indirizzi IP degli host che devono comunicare con la destinazione. Le API devono essere pubblicizzate nell'ambiente in cui l'API target (ad esempio, gli indirizzi IP del richiedente API (il client). La un'eccezione è quando la comunicazione avviene attraverso un bilanciatore del carico, Endpoint Private Service Connect o istanza NAT.
Per estendere la connettività all'ambiente remoto, questa progettazione utilizza una rete VPC diretta il peering con scambio percorso cliente funzionalità. La progettazione consente a specifiche richieste API provenienti dai carichi di lavoro ospitato nel VPC dell'applicazione Google Cloud per il routing attraverso il VPC di transito. In alternativa, puoi utilizzare un endpoint Private Service Connect il VPC dell'applicazione associato a un carico con un backend di gruppo di endpoint di rete ibrido nel VPC di transito. Questo viene descritta nella sezione successiva: Comunicazione API bidirezionale con Private Service Connect.
Comunicazione API bidirezionale con Private Service Connect
A volte le aziende potrebbero non aver bisogno di utilizzare un gateway API (come Apigee) immediatamente o potresti volerlo aggiungere in un secondo momento. Tuttavia, potrebbero essere previsti requisiti aziendali che consentono la comunicazione e l'integrazione tra determinate applicazioni ambienti cloud-native. Ad esempio, se la tua azienda ha acquisito un'altra azienda, potresti dover esporre determinate applicazioni all'azienda. Potrebbe essere necessario esporre applicazioni alla tua azienda. Entrambe le aziende potrebbero avere ciascuno i propri carichi di lavoro ospitati in ambienti diversi (Google Cloud, on-premise o cloud) ed evitare la sovrapposizione di indirizzi IP. In questi casi, puoi utilizzare Private Service Connect per facilitare una comunicazione efficace.
Per le applicazioni utilizzate come API, puoi anche Private Service Connect per fornire un indirizzo privato per le applicazioni pubblicate, consentendo l'accesso sicuro all'interno più regioni e tramite connettività ibrida. Questa astrazione Semplifica l'integrazione di risorse da diversi cloud e on-premise ambienti su un modello di connettività ibrida e multi-cloud. Inoltre, consente l'assemblaggio di applicazioni in ambienti multi-cloud e on-premise. Può soddisfare diversi requisiti di comunicazione, come l'integrazione sicura in cui non viene usato un gateway API o non è previsto l'uso.
Utilizzando Private Service Connect con Cloud Load Balancing, come illustrato di seguito di comunicazione, puoi definire due percorsi di comunicazione distinti. Ogni percorso avviato da una direzione diversa per uno scopo di connettività separato, idealmente tramite le chiamate API.
- Tutte le considerazioni sulla progettazione e i suggerimenti di Private Service Connect discussi in questa guida si applica a questa struttura.
- Se è necessaria un'ulteriore ispezione di livello 7, puoi integrare gli NVA con questa progettazione (nel VPC di transito).
- Questa progettazione può essere utilizzata con o senza gateway API.
I due percorsi di connettività illustrati nel diagramma precedente rappresentano connessioni indipendenti e non illustrano la comunicazione bidirezionale una connessione o un flusso di lavoro.
Comunicazione bidirezionale utilizzando endpoint e interfacce Private Service Connect
Come discusso nel Pattern in entrata con accesso riservato, una delle opzioni per abilitare la comunicazione client-servizio è l'utilizzo di un Endpoint Private Service Connect per esporre un servizio in un producer a un VPC consumer. Questo la connettività può essere estesa a un ambiente on-premise o anche a un altro cloud dell'ambiente del provider su una connettività ibrida. Tuttavia, in alcuni scenari, può richiedere anche una comunicazione privata.
Per accedere a un determinato servizio, ad esempio recuperare dati da origini dati che possono essere in hosting all'interno o all'esterno del VPC consumer, questa comunicazione privata tra il VPC dell'applicazione (producer) e un ambiente remoto, come dell'ambiente on-premise.
In questo scenario, Interfacce Private Service Connect abilitare un'istanza VM di un producer di servizi per accedere alla rete di un consumer. Per farlo, condivide un'interfaccia di rete, pur mantenendo il separazione tra produttore e consumatore. Con questa interfaccia di rete VPC consumer, la VM dell'applicazione può accedere alle risorse consumer come se risiedevano localmente nel VPC del producer.
Un'interfaccia di Private Service Connect è un'interfaccia di rete collegato al VPC consumer (di transito). È possibile raggiungere destinazioni raggiungibili dal VPC consumer (transito) dove L'interfaccia di Private Service Connect è collegata. Pertanto, questa connessione può essere estesa a un ambiente esterno su una come un ambiente on-premise, come illustrato in diagramma seguente:
Se il VPC consumer è un'organizzazione o un'entità esterna, ad esempio una terza parte dell'organizzazione, in genere non si avrà la possibilità di proteggere le comunicazioni all'interfaccia Private Service Connect nel VPC consumer. Nella in uno scenario di questo tipo, è possibile definire i criteri di sicurezza nel sistema operativo guest VM dell'interfaccia Private Service Connect. Per ulteriori informazioni, vedi Configura la sicurezza per le interfacce di Private Service Connect. Potresti anche prendere in considerazione un approccio alternativo se non è conforme alle la conformità o gli standard di sicurezza della tua organizzazione.
Best practice
Per situazioni in cui le richieste del client da internet devono ricevuti localmente da un frontend ospitato in un ambiente on-premise privato o nell'ambiente cloud, valuta la possibilità di utilizzare il cloud ibrido come API gateway VPN ad alta disponibilità.
- Questo approccio facilita anche la migrazione della soluzione ospitato completamente da Google Cloud, mantenendo al contempo e coerenza della piattaforma API (Apigee).
Per ridurre al minimo la latenza e ottimizzare i costi per volumi elevati di dati in uscita vengono trasferiti agli altri tuoi ambienti, quando questi ambienti configurazioni ibride o multi-cloud permanenti o a lungo termine, considera quanto segue:
- Usa Cloud Interconnect o Cross-Cloud Interconnect.
- Per terminare le connessioni utente al frontend di destinazione nel l'ambiente appropriato, usa Ibrido.
Ove applicabile ai tuoi requisiti e all'architettura, usa Adattatore Apigee per Envoy con un Deployment ibrido con Kubernetes.
Prima di progettare la connettività e i percorsi di routing, identificare le richieste API o di traffico da indirizzare a un gateway API remoto, insieme agli ambienti di origine e di destinazione.
Utilizza i Controlli di servizio VPC per proteggere i servizi Google Cloud nel tuo e per mitigare il rischio di esfiltrazione di dati, specificando perimetri di servizio a livello di progetto o di rete VPC.
- Puoi estendere i perimetri di servizio in un ambiente ibrido su VPN autorizzata e Cloud Interconnect. Per ulteriori informazioni sui vantaggi delle perimetri di servizio, Panoramica dei Controlli di servizio VPC.
Utilizza le funzionalità di Regole firewall Virtual Private Cloud (VPC) o criteri firewall per controllare l'accesso a livello di rete a Private Service Connect tramite l'endpoint Private Service Connect. Ad esempio: regole firewall in uscita al VPC dell'applicazione (consumer) può limitare l'accesso dalle istanze VM a l'indirizzo IP o la subnet dei tuoi endpoint.
Quando utilizzi un'interfaccia Private Service Connect, è necessario proteggere la comunicazione a livello di server configurando la sicurezza Interfaccia di Private Service Connect.
Se un carico di lavoro in una subnet privata richiede l'accesso a internet, usa Cloud NAT per evitare di assegnare un indirizzo IP esterno al carico di lavoro ed esporlo a nella rete internet pubblica.
- Per il traffico web in uscita, utilizza Secure Web Proxy. Il proxy offre diversi vantaggi.
Esamina il best practice generali per pattern di networking ibridi e multi-cloud.