Il pattern Uscita controllata e ingresso controllato utilizza una combinazione di uscita controllata e ingresso controllato per gli scenari che richiedono l'utilizzo 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 è limitata alle API esposte o ad indirizzi IP specifici, le reti degli ambienti non devono essere allineate nel design. Gli scenari comuni applicabili includono, a titolo esemplificativo:
- Fusioni e acquisizioni.
- Integrazioni delle applicazioni con i partner.
- Integrazioni tra applicazioni e servizi di un'organizzazione con diverse unità organizzative che gestiscono le proprie applicazioni e le ospitano in ambienti diversi.
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 con indirizzi IP di destinazione specifici) utilizzando indirizzi IP interni. Altri sistemi distribuiti nell'ambiente di computing 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. Non è possibile raggiungere altri sistemi di cui è stato eseguito il deployment in Google Cloud.
Architettura
Il seguente diagramma mostra un'architettura di riferimento per il pattern di uscita gated e di ingresso gated:
L'approccio di progettazione nel diagramma precedente prevede i seguenti elementi:
- Sul lato di Google Cloud, esegui il deployment dei carichi di lavoro in un VPC (o in un VPC condiviso) senza esporli direttamente a internet.
- La rete dell'ambiente Google Cloud viene estesa ad altri ambienti di calcolo. L'ambiente può essere on-premise o su un altro cloud. Per estendere l'ambiente, utilizza un pattern di comunicazione per la connettività ibrida e multi-cloud adatto 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 Cloud Next Generation Firewall o appliance virtuali di rete (NVA) con firewall di nuova generazione (NGFW) nel VPC di transito per ispezionare il traffico e consentire o vietare l'accesso a determinate API da origini specifiche prima che raggiungano 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 per l'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). Con l'evoluzione delle applicazioni e la migrazione al cloud, spesso emergono dipendenze e preferenze per servizi cloud specifici.
A volte, queste dipendenze e preferenze comportano la distribuzione di applicazioni e backend su 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 la distribuzione graduale dei componenti dell'applicazione in ambienti diversi. 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 è utile per:
- Facilita la comunicazione bidirezionale tra Google Cloud, on-premise e altri ambienti cloud utilizzando API predefinite su entrambi i lati in linea con il modello di comunicazione di questo pattern.
- Per fornire frontend globali per le applicazioni rivolte a internet con componenti dell'applicazione distribuiti (frontend o backend) e per raggiungere i seguenti obiettivi, puoi utilizzare le funzionalità di bilanciamento del carico e di sicurezza avanzate di Google Cloud distribuite nei point of presence (PoP):
- Riduci le spese in conto capitale e semplifica le operazioni utilizzando e senza server.
- Ottimizza le connessioni ai backend delle applicazioni a livello globale per velocità
e latenza.
- Cross-Cloud Network di Google Cloud consente la comunicazione multicloud tra i componenti dell'applicazione tramite connessioni private ottimali.
- Memorizza nella cache i contenuti statici ad alta domanda e migliora le prestazioni delle applicazioni che utilizzano Cloud Load Balancing globale fornendo l'accesso a Cloud CDN.
- Proteggi i frontend globali delle applicazioni rivolte a internet utilizzando le funzionalità di Google Cloud Armor che forniscono servizi WAF (web application firewall) e di mitigazione degli attacchi DDoS distribuiti a livello globale.
- Facoltativamente, puoi incorporare Private Service Connect nel tuo design. In questo modo, l'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 con uscita e ingresso controllati possono essere combinati con altri approcci per soddisfare requisiti di progettazione diversi, tenendo comunque conto dei requisiti di comunicazione di questo pattern. I pattern offrono quanto segue: opzioni:
- Gateway API distribuiti
- Comunicazione bidirezionale dell'API mediante Private Service Connect
- Comunicazione bidirezionale mediante 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, compreso un ambiente privato on-premise. Il requisito comune è instradare le richieste del client al frontend dell'applicazione direttamente nell'ambiente 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 come Apigee e Apigee Hybrid sono progettati per soddisfare questi requisiti con un API Gateway localizzato in ogni ambiente. La gestione della piattaforma API è centralizzata in Google Cloud. Questo design consente di applicare misure di controllo dell'accesso rigorose in cui solo gli indirizzi IP preapprovati (API di destinazione e di destinazione o indirizzi IP degli 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 API e i proxy all'interno di ogni ambiente gestiscono le richieste API di client e applicazioni in direzioni diverse in più ambienti.
- Funzionalità gateway API in Google Cloud (Apigee) espone l'applicazione (frontend o backend) ospitati in Google Cloud.
- La funzionalità di API Gateway in un altro ambiente (ibrido) espone i componenti frontend (o backend) dell'applicazione 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, questo design utilizza il peering VPC diretto con la funzionalità di scambio di route dei clienti. Il design consente di instradare tramite il VPC di transito richieste API specifiche provenienti da carichi di lavoro ospitati all'interno del VPC dell'applicazione Google Cloud. In alternativa, puoi utilizzare un endpoint Private Service Connect nel VPC dell'applicazione associato a un bilanciatore del carico con un backend del gruppo di endpoint di rete ibrida 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 esserci requisiti aziendali per attivare la comunicazione e l'integrazione tra determinate applicazioni in ambienti diversi. Ad esempio, se la tua azienda ha acquisito un'altra azienda, potresti dover esporre determinate applicazioni a questa azienda. Potrebbe essere necessario esporre applicazioni alla tua azienda. Entrambe le aziende potrebbero avere i propri carichi di lavoro ospitati in ambienti diversi (Google Cloud, on-premise o in altri cloud) e devono evitare la sovrapposizione degli indirizzi IP. In questi casi, puoi utilizzare Private Service Connect per facilitare una comunicazione efficace.
Per le applicazioni utilizzate come API, puoi anche utilizzare Private Service Connect per fornire un indirizzo privato per le applicazioni pubblicate, consentendo l'accesso sicuro all'interno della rete privata nelle varie regioni e tramite la connettività ibrida. Questa astrazione facilita l'integrazione delle risorse da diversi cloud e ambienti on-premise tramite 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 mostrato nel seguente diagramma, puoi ottenere due percorsi di comunicazione distinti. Ogni percorso avviato da una direzione diversa per uno scopo di connettività separato, idealmente tramite le chiamate API.
- A questo design si applicano tutte le considerazioni e i consigli di progettazione di Private Service Connect discussi in questa guida.
- Se è necessaria un'ispezione aggiuntiva a livello 7, puoi integrare le NVA con questo design (nella VPC di transito).
- Questo design può essere utilizzato 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 mediante endpoint e interfacce Private Service Connect
Come discusso nel pattern di ingresso gated, una delle opzioni per abilitare la comunicazione tra client e servizio è utilizzare un endpoint Private Service Connect per esporre un servizio in un VPC 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 per recuperare i dati da origini dati che possono essere ospitate all'interno o all'esterno del VPC del consumatore, questa comunicazione privata può avvenire tra il VPC dell'applicazione (del producer) e un ambiente remoto, ad esempio un 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 (di 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. In questo scenario, puoi definire i criteri di sicurezza nel sistema operativo guest della VM dell'interfaccia Private Service Connect. Per ulteriori informazioni, consulta Configurare la sicurezza per le interfacce 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 trasferimenti di dati in uscita verso gli altri ambienti quando questi sono in configurazioni ibride o multicloud permanenti o a lungo termine, tieni presente quanto segue:
- Usa Cloud Interconnect o Cross-Cloud Interconnect.
- Per terminare le connessioni degli utenti nel frontend di destinazione nell'ambiente appropriato, utilizza Ibrida.
Ove applicabile ai tuoi requisiti e all'architettura, usa Adattatore Apigee per Envoy con un Deployment ibrido con Kubernetes.
Prima di progettare i percorsi di connettività e di routing, devi identificare il traffico o le richieste API da indirizzare a un API Gateway locale o remoto, nonché gli 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 regole del firewall Virtual Private Cloud (VPC) o criteri del firewall per controllare l'accesso a livello di rete alle risorse 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, devi proteggere la comunicazione con l'interfaccia configurando la sicurezza per l'interfaccia Private Service Connect.
Se un carico di lavoro in una subnet privata richiede l'accesso a internet, utilizza Cloud NAT per evitare di assegnare un indirizzo IP esterno al carico di lavoro e di esporlo all'internet pubblico.
- 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.