L'architettura del pattern gated ingress si basa sull'esposizione di API selezionate dei carichi di lavoro in esecuzione in Google Cloud all'ambiente di computing privato senza esporle a internet pubblico. Questo pattern è la controparte del pattern uscita controllata ed è adatto agli scenari ibrido edge, ibrido a livelli e multi-cloud partizionato.
Come nel caso del pattern di uscita controllata, puoi facilitare questa esposizione limitata tramite un gateway API o un bilanciamento del carico che funge da facciata per servizi o carichi di lavoro esistenti. In questo modo, diventa accessibile a ambienti di computing privati, ambienti on-premise o in altri ambienti cloud, come segue:
- I workload che implementi nell'ambiente di computing privato o in altri ambienti cloud possono comunicare con il gateway API o il bilanciatore del carico utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi diGoogle Cloud .
- La comunicazione da Google Cloud all'ambiente di calcolo privato o ad altri ambienti cloud non è consentita. Il traffico viene avviato solo dall'ambiente privato o da altri ambienti cloud alle API in Google Cloud.
Architettura
Il seguente diagramma mostra un'architettura di riferimento che soddisfa i requisiti del pattern di ingresso controllato.
La descrizione dell'architettura nel diagramma precedente è la seguente:
- Sul lato Google Cloud , esegui il deployment dei carichi di lavoro in un VPC dell'applicazione (o in più VPC).
- La rete dell'ambiente Google Cloud si estende ad altri ambienti di computing (on-premise o su un altro cloud) utilizzando la connettività di rete ibrida o multicloud per facilitare la comunicazione tra gli ambienti.
- Se vuoi, puoi utilizzare un VPC di transito per eseguire le seguenti operazioni:
- Fornisci ulteriori livelli di sicurezza perimetrale per consentire l'accesso a API specifiche al di fuori del VPC dell'applicazione.
- Instrada il traffico verso gli indirizzi IP delle API. Puoi creare regole firewall VPC per impedire ad alcune origini di accedere a determinate API tramite un endpoint.
- Ispeziona il traffico di livello 7 nel VPC di transito integrando un'appliance virtuale di rete (NVA).
- Accedi alle API tramite un gateway API o un bilanciatore del carico (proxy o bilanciatore del carico delle applicazioni) per fornire un livello proxy e un livello di astrazione o una facciata per le API di servizio. Se devi distribuire il traffico su più istanze del gateway API, puoi utilizzare un bilanciatore del carico di rete passthrough interno.
- Fornisci un accesso limitato e granulare a un servizio pubblicato tramite un endpoint Private Service Connect utilizzando un bilanciatore del carico tramite Private Service Connect per esporre un'applicazione o un servizio.
- Tutti gli ambienti devono utilizzare uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
Il seguente diagramma illustra la progettazione di questo pattern utilizzando Apigee come piattaforma API.
Nel diagramma precedente, l'utilizzo di Apigee come piattaforma API fornisce le seguenti funzionalità per abilitare il pattern ingresso controllato:
- Funzionalità di gateway o proxy
- Funzionalità di sicurezza
- Limitazione di frequenza
- Analytics
Nel design:
- La connettività di rete in direzione nord (per il traffico proveniente da altri ambienti) passa attraverso un endpoint Private Service Connect nel VPC dell'applicazione associato al VPC Apigee.
- Nel VPC dell'applicazione, un bilanciatore del carico interno viene utilizzato per esporre le API dell'applicazione tramite un endpoint Private Service Connect presentato nel VPC Apigee. Per maggiori informazioni, consulta Architettura con peering VPC disattivato.
Configura le regole firewall e il filtro del traffico nel VPC dell'applicazione. In questo modo, l'accesso è granulare e controllato. Inoltre, impedisce ai sistemi di raggiungere direttamente le tue applicazioni senza passare attraverso l'endpoint Private Service Connect e il gateway API.
Inoltre, puoi limitare la pubblicità della subnet dell'indirizzo IP interno del carico di lavoro di backend nel VPC dell'applicazione alla rete on-premise per evitare la raggiungibilità diretta senza passare attraverso l'endpoint Private Service Connect e il gateway API.
Alcuni requisiti di sicurezza potrebbero richiedere l'ispezione della sicurezza perimetrale al di fuori del VPC dell'applicazione, incluso il traffico di connettività ibrida. In questi casi, puoi incorporare un VPC di transito per implementare ulteriori livelli di sicurezza. Questi livelli, come le NVA dei firewall di nuova generazione (NGFW) con più interfacce di rete o Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS), eseguono l'ispezione approfondita dei pacchetti al di fuori del VPC dell'applicazione, come illustrato nel seguente diagramma:
Come illustrato nel diagramma precedente:
- La connettività di rete in direzione nord (per il traffico proveniente da altri ambienti) passa attraverso un VPC di transito separato verso l'endpoint Private Service Connect nel VPC di transito associato al VPC Apigee.
- Nel VPC dell'applicazione, un bilanciatore del carico interno (ILB nel diagramma) viene utilizzato per esporre l'applicazione tramite un endpoint Private Service Connect nel VPC Apigee.
Puoi eseguire il provisioning di più endpoint nella stessa rete VPC, come mostrato nel diagramma seguente. Per coprire diversi casi d'uso, puoi controllare i diversi percorsi di rete possibili utilizzando router Cloud e le regole firewall VPC. Ad esempio, se connetti la tua rete on-premise a Google Cloud utilizzando più connessioni di rete ibrida, puoi inviare parte del traffico on-premise a API Google specifiche o a servizi pubblicati tramite una connessione e il resto tramite un'altra connessione. Inoltre, puoi utilizzare l'accesso globale di Private Service Connect per fornire opzioni di failover.
Varianti
Il pattern di architettura gated ingress può essere combinato con altri approcci per soddisfare diversi requisiti di progettazione, tenendo comunque conto dei requisiti di comunicazione del pattern. Il pattern offre le seguenti opzioni:
Esporre i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect
Utilizza un'architettura hub-and-spoke per esporre i backend delle applicazioni ad altri ambienti
Accedere alle API di Google da altri ambienti
Per gli scenari che richiedono l'accesso ai servizi Google, come Cloud Storage o BigQuery, senza inviare traffico sulla rete internet pubblica, Private Service Connect offre una soluzione. Come mostrato nel diagramma seguente, consente la raggiungibilità alle API di Google supportate e ai servizi (inclusi Google Maps, Google Ads e Google Cloud) da ambienti on-premise o da altri ambienti cloud tramite una connessione di rete ibrida utilizzando l'indirizzo IP dell'endpoint Private Service Connect. Per ulteriori informazioni sull'accesso alle API di Google tramite gli endpoint Private Service Connect, consulta Informazioni sull'accesso alle API di Google tramite endpoint.
Nel diagramma precedente, la rete on-premise deve essere connessa alla rete VPC di transito (consumer) utilizzando tunnel Cloud VPN o un collegamento VLAN di Cloud Interconnect.
È possibile accedere alle API di Google utilizzando endpoint o backend. Gli endpoint consentono di scegliere come target un bundle di API di Google. I backend ti consentono di scegliere come target un'API Google regionale specifica.
Esporre i backend delle applicazioni ad altri ambienti utilizzando Private Service Connect
In scenari specifici, come evidenziato dal pattern ibrido a livelli, potresti dover eseguire il deployment dei backend in Google Cloud mantenendo i frontend in ambienti di computing privati. Sebbene meno comune, questo approccio è applicabile quando si ha a che fare con frontend monolitici e pesanti che potrebbero basarsi su componenti legacy. Oppure, più comunemente, quando si gestiscono applicazioni distribuite in più ambienti, inclusi on-premise e altri cloud, che richiedono la connettività ai backend ospitati in Google Cloud su una rete ibrida.
In un'architettura di questo tipo, puoi utilizzare un bilanciatore del carico o un gateway API locale nell'ambiente on-premise privato o in altri ambienti cloud per esporre direttamente il frontend dell'applicazione alla rete internet pubblica. L'utilizzo di Private Service Connect in Google Cloud facilita la connettività privata ai backend esposti tramite un endpoint Private Service Connect, idealmente utilizzando API predefinite, come illustrato nel seguente diagramma:
Il design nel diagramma precedente utilizza un deployment di Apigee Hybrid costituito da un piano di gestione in Google Cloud e un piano di runtime ospitato nell'altro ambiente. Puoi installare e gestire il piano di runtime su un gateway API distribuito su una delle piattaforme Kubernetes supportate nel tuo ambiente on-premise o in altri ambienti cloud. In base ai tuoi requisiti per i workload distribuiti su Google Cloud e altri ambienti, puoi utilizzare Apigee su Google Cloud con Apigee Hybrid. Per ulteriori informazioni, vedi Gateway API distribuiti.
Utilizza un'architettura hub and spoke per esporre i backend delle applicazioni ad altri ambienti
In alcuni scenari potrebbe essere necessario esporre API dai backend delle applicazioni ospitati in Google Cloud in diverse reti VPC. Come illustrato nel diagramma seguente, un VPC hub funge da punto centrale di interconnessione per i vari VPC (spoke), consentendo una comunicazione sicura tramite connettività ibrida privata. Facoltativamente, le funzionalità del gateway API locale in altri ambienti, come Apigee Hybrid, possono essere utilizzate per terminare le richieste client localmente, dove è ospitato il frontend dell'applicazione.
Come illustrato nel diagramma precedente:
- Per fornire ulteriori funzionalità di ispezione di livello 7 di NGFW, la NVA con funzionalità NGFW è integrata facoltativamente nella progettazione. Potresti richiedere queste funzionalità per rispettare requisiti di sicurezza specifici e gli standard delle norme di sicurezza della tua organizzazione.
Questo progetto presuppone che i VPC spoke non richiedano la comunicazione diretta da VPC a VPC.
- Se è necessaria la comunicazione hub-spoke, puoi utilizzare NVA per facilitare questa comunicazione.
- Se hai backend diversi in VPC diversi, puoi utilizzare Private Service Connect per esporre questi backend al VPC Apigee.
- Se il peering VPC viene utilizzato per la connettività
northbound e southbound tra i VPC spoke e il VPC hub, devi considerare la
limitazione di transitività
del networking VPC tramite il peering VPC. Per superare questa limitazione, puoi utilizzare una delle seguenti opzioni:
- Per interconnettere i VPC, utilizza una NVA.
- Se applicabile, considera il modello Private Service Connect.
- Per stabilire la connettività tra il VPC Apigee e i backend che si trovano in altri progettiGoogle Cloud nella stessa organizzazione senza componenti di rete aggiuntivi, utilizza il VPC condiviso.
Se sono richieste NVA per l'ispezione del traffico, incluso il traffico proveniente dagli altri ambienti, la connettività ibrida agli ambienti on-premise o ad altri ambienti cloud deve essere terminata nel VPC di transito ibrido.
Se la progettazione non include la NVA, puoi terminare la connettività ibrida nel VPC hub.
Se sono richieste determinate funzionalità di bilanciamento del carico o funzionalità di sicurezza, come l'aggiunta della protezione DDoS o del WAF di Google Cloud Armor, puoi facoltativamente eseguire il deployment di un bilanciatore del carico delle applicazioni esterno perimetrale tramite un VPC esterno prima di instradare le richieste dei client esterni ai backend.
Best practice
- Per le situazioni in cui le richieste client da internet devono essere ricevute localmente da un frontend ospitato in un ambiente on-premise privato o in un altro ambiente cloud, valuta la possibilità di utilizzare Apigee Hybrid come soluzione di gateway API. Questo approccio facilita anche la migrazione senza problemi della soluzione a un ambiente completamente ospitato Google Cloud, mantenendo la coerenza della piattaforma API (Apigee).
- Utilizza l'adattatore Apigee per Envoy con un'architettura di deployment Apigee Hybrid con Kubernetes, se applicabile ai tuoi requisiti e all'architettura.
- La progettazione di VPC e progetti in Google Cloud deve seguire i requisiti della gerarchia delle risorse e del modello di comunicazione sicuro, come descritto in questa guida.
- L'incorporamento di un VPC di transito in questa progettazione offre la flessibilità di eseguire il provisioning di misure di sicurezza perimetrale aggiuntive e della connettività ibrida al di fuori del VPC del carico di lavoro.
- Utilizza Private Service Connect per accedere alle API e ai servizi Google da ambienti on-premise o da altri ambienti cloud utilizzando l'indirizzo IP interno dell'endpoint su una rete di connettività ibrida. Per saperne di più, vedi Accedere all'endpoint da host on-premise.
- Per proteggere i servizi nei tuoi progetti e contribuire a mitigare il rischio di esfiltrazione di dati, utilizza Controlli di servizio VPC per specificare i perimetri di servizio a livello di progetto o di rete VPC. Google Cloud
- Se necessario, puoi estendere i service perimeter a un ambiente ibrido tramite una VPN o Cloud Interconnect. Per maggiori informazioni sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.
- Utilizza le regole firewall VPC o le policy firewall per controllare l'accesso a livello di rete alle risorse Private Service Connect tramite l'endpoint Private Service Connect. Ad esempio, le regole firewall in uscita nel VPC dell'applicazione (consumer) possono limitare l'accesso dalle istanze VM all'indirizzo IP o alla subnet degli endpoint. Per ulteriori informazioni sulle regole firewall VPC in generale, consulta Regole firewall VPC.
- Quando progetti una soluzione che include NVA, è importante considerare l'alta disponibilità (HA) delle NVA per evitare un singolo punto di errore che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni per la progettazione e l'implementazione dell'alta disponibilità e della ridondanza fornite dal fornitore della NVA.
- Per rafforzare la sicurezza perimetrale e proteggere il gateway API distribuito nell'ambiente corrispondente, puoi implementare facoltativamente meccanismi di bilanciamento del carico e web application firewall nell'altro ambiente di computing (ibrido o altro cloud). Implementa queste opzioni nella rete perimetrale direttamente connessa a internet.
- Se le istanze richiedono l'accesso a internet, utilizza Cloud NAT nel VPC dell'applicazione per consentire ai carichi di lavoro di accedere a internet. In questo modo puoi evitare di assegnare istanze VM con indirizzi IP pubblici esterni nei sistemi di cui è stato eseguito il deployment dietro un gateway API o un bilanciatore del carico.
- Per il traffico web in uscita, utilizza Secure Web Proxy. Il proxy offre diversi vantaggi.
- Consulta le best practice generali per i pattern di networking ibrido e multicloud.