I pattern in uscita con accesso riservato e in entrata con accesso riservato utilizzano una combinazione di traffico in uscita riservato e in entrata con accesso riservato per 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 ambienti on-premise privati o in altri ambienti cloud. In questo pattern, è possibile utilizzare gateway API, endpoint Private Service Connect o bilanciatori del carico per esporre API specifiche e, facoltativamente, fornire controlli di autenticazione, autorizzazione e chiamata API.
La principale distinzione tra questo pattern e il pattern mesh nella sua applicazione risiede in scenari che richiedono esclusivamente l'utilizzo bidirezionale dell'API o la comunicazione con origini e destinazioni di indirizzi IP specifici, ad esempio un'applicazione pubblicata tramite un endpoint Private Service Connect. Poiché la comunicazione è limitata alle API esposte o agli indirizzi IP specifici, le reti tra gli ambienti non devono essere allineate nel progetto. Gli 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 le 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 gli indirizzi IP di destinazione specifici) utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi distribuiti nell'ambiente di calcolo privato.
- Al contrario, i carichi di lavoro di cui esegui il deployment in altri ambienti di computing possono comunicare con il gateway API lato Google Cloud (o con uno specifico indirizzo IP dell'endpoint pubblicato) utilizzando indirizzi IP interni. Altri sistemi di cui è stato eseguito il deployment in Google Cloud non sono raggiungibili.
Architettura
Il seguente diagramma mostra un'architettura di riferimento per il traffico in uscita con accesso riservato e il pattern 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 (o VPC condiviso) senza esporli direttamente a internet.
- La rete dell'ambiente Google Cloud è estesa ad altri ambienti di computing. L'ambiente può essere on-premise o su un altro cloud. Per estendere l'ambiente, utilizza un modello di comunicazione con connettività ibrida e multi-cloud adatto per facilitare la comunicazione tra gli ambienti, in modo che possano utilizzare indirizzi IP interni.
- Facoltativamente, abilitando l'accesso a indirizzi IP di destinazione specifici, puoi utilizzare un VPC di transito per aggiungere un livello di sicurezza perimetrale al di fuori del 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 di raggiungere il VPC dell'applicazione.
- Le API devono essere accessibili tramite un gateway API o un bilanciatore del carico per fornire un livello di proxy e un'astrazione o un'interfaccia per le API di servizio.
- Per le applicazioni utilizzate come API, puoi anche utilizzare Private Service Connect per fornire un 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 di un sottoinsieme di backend delle applicazioni) in Google Cloud durante l'hosting di altri componenti di backend e frontend in ambienti on-premise o in altri cloud (pattern ibrido a livelli o multi-cloud partizionato). Man mano che le applicazioni evolvono e migrano nel cloud, spesso emergono dipendenze e preferenze per servizi cloud specifici.
A volte, queste dipendenze e preferenze portano alla distribuzione di applicazioni e backend tra diversi cloud provider. Inoltre, alcune applicazioni potrebbero essere create con una combinazione di risorse e servizi distribuiti in ambienti on-premise e in più ambienti cloud.
Per le applicazioni distribuite, è possibile utilizzare le funzionalità della connettività ibrida e multi-cloud esterna di Cloud Load Balancing per terminare le richieste degli utenti e instradarle a frontend o backend in altri ambienti. Questo routing avviene tramite una connessione di rete ibrida, come illustrato nel diagramma seguente. Questa integrazione consente la distribuzione graduale dei componenti delle applicazioni tra diversi ambienti. Le richieste dal frontend ai servizi di backend ospitati in Google Cloud comunicano in modo sicuro sulla connessione di rete ibrida stabilita, facilitata da un bilanciatore del carico interno (ILB nel diagramma).
L'utilizzo del design di Google Cloud nel diagramma precedente aiuta a:
- Facilita la comunicazione bidirezionale tra Google Cloud, on-premise e altri ambienti cloud utilizzando API predefinite su entrambi i lati che si allineano al modello di comunicazione di questo pattern.
- Per fornire frontend globali per le applicazioni per internet con componenti delle applicazioni distribuiti (frontend o backend) e raggiungere i seguenti obiettivi, puoi utilizzare le funzionalità avanzate di bilanciamento del carico e sicurezza di Google Cloud, distribuiti nei punti di presenza (PoP):
- Riduci le spese in conto capitale e semplifica le operazioni utilizzando i servizi gestiti serverless.
- Ottimizzare le connessioni ai backend delle
applicazioni a livello globale in termini di velocità e latenza.
- La rete Cross-Cloud di Google Cloud consente la comunicazione multi-cloud tra i componenti dell'applicazione tramite connessioni private ottimali.
- Memorizza nella cache contenuti statici ad alta domanda e migliora le prestazioni delle applicazioni 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 servizi WAF (Web Application Firewall) distribuiti a livello globale e di mitigazione degli attacchi DDoS.
- Se vuoi, puoi incorporare Private Service Connect nel tuo progetto. In questo modo consenti un accesso privato e granulare alle API dei servizi Google Cloud o ai tuoi servizi pubblicati da altri ambienti senza attraversare la rete internet pubblica.
Varianti
I pattern di architettura di traffico in uscita riservato e in entrata con accesso riservato possono essere combinati con altri approcci per soddisfare diversi requisiti di progettazione, pur continuando a considerare i requisiti di comunicazione di questo pattern. I pattern offrono le seguenti 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 sul pattern multi-cloud partizionato, le applicazioni (o i componenti delle applicazioni) possono essere creati in diversi ambienti cloud, compreso un ambiente on-premise privato. Il requisito comune è quello di 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 funzionalità specifiche della piattaforma API per l'integrazione.
Il seguente diagramma illustra il modo in cui Apigee e Apigee Hybrid sono progettati per soddisfare questi requisiti con un gateway API localizzato in ogni ambiente. La gestione della piattaforma API è centralizzata in Google Cloud. Questa progettazione consente di applicare rigide misure di controllo dell'accesso, laddove solo gli indirizzi IP preapprovati (API di destinazione e destinazione o indirizzi IP degli endpoint Private Service Connect) possono comunicare tra Google Cloud e gli altri ambienti.
L'elenco seguente descrive i due percorsi di comunicazione distinti nel diagramma precedente che utilizzano il gateway API Apigee:
- Le richieste del client arrivano al frontend dell'applicazione direttamente nell'ambiente che ospita l'applicazione (o il componente frontend).
- I gateway e i proxy API all'interno di ciascun ambiente gestiscono le richieste API del client e delle applicazioni in direzioni diverse e in diversi ambienti.
- La funzionalità gateway API in Google Cloud (Apigee) espone i componenti dell'applicazione (frontend o backend) ospitati in Google Cloud.
- La funzionalità gateway API 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ò offrire flessibilità per separare i problemi ed eseguire l'ispezione di sicurezza e la connettività ibrida in una rete VPC separata. Dal punto di vista della raggiungibilità di un indirizzo IP, un VPC di transito (a cui è collegata la connettività ibrida) semplifica i seguenti requisiti per mantenere la connettività end-to-end:
- Gli indirizzi IP per le API di destinazione devono essere pubblicizzati negli altri ambienti in cui sono ospitati i client/richiedenti.
- Gli indirizzi IP degli host che devono comunicare con le API target devono essere pubblicizzati nell'ambiente in cui si trova l'API target, ad esempio gli indirizzi IP del richiedente API (il client). L'eccezione è quando la comunicazione avviene attraverso un bilanciatore del carico, un proxy, un endpoint Private Service Connect o un'istanza NAT.
Per estendere la connettività all'ambiente remoto, questa progettazione utilizza il peering VPC diretto con funzionalità di scambio di route cliente. La progettazione consente a richieste API specifiche provenienti da carichi di lavoro ospitati all'interno del VPC dell'applicazione Google Cloud di instradare un VPC di transito. In alternativa, puoi utilizzare un endpoint Private Service Connect nel VPC dell'applicazione associato a un bilanciatore del carico con un backend di gruppo di endpoint di rete ibrido nel VPC di transito. Questa configurazione è 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 immediatamente un gateway API (come Apigee) o potrebbero volerlo aggiungere in un secondo momento. Tuttavia, potrebbero sussistere requisiti aziendali per consentire la comunicazione e l'integrazione tra determinate applicazioni in ambienti diversi. Ad esempio, se la tua azienda ha acquisito un'altra, potrebbe essere necessario esporre a quell'azienda determinate applicazioni. Potrebbe dover esporre le 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 di indirizzi IP. In questi casi, puoi usare 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 tra regioni e tramite connettività ibrida. Questa astrazione facilita l'integrazione di risorse da diversi cloud e ambienti on-premise su un modello di connettività ibrida e multi-cloud. Consente inoltre l'assemblaggio di applicazioni in ambienti multi-cloud e on-premise. Questo può soddisfare diversi requisiti di comunicazione, come l'integrazione di applicazioni sicure in cui non viene utilizzato un gateway API o non è previsto l'uso di un gateway.
Utilizzando Private Service Connect con Cloud Load Balancing, come illustrato nel seguente diagramma, puoi ottenere due percorsi di comunicazione distinti. Ogni percorso viene avviato da una direzione diversa per uno scopo di connettività distinto, possibilmente tramite chiamate API.
- Tutte le considerazioni sulla progettazione e i suggerimenti di Private Service Connect discussi in questa guida si applicano alla progettazione.
- Se è necessaria un'ispezione aggiuntiva 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 di una singola connessione o flusso.
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 VPC del producer a un VPC consumer. Questa connettività può essere estesa a un ambiente on-premise o anche a un altro ambiente cloud provider tramite una connettività ibrida. Tuttavia, in alcuni scenari, il servizio in hosting può richiedere anche una comunicazione privata.
Per accedere a un determinato servizio, ad esempio recuperare dati da origini dati che possono essere ospitate all'interno o all'esterno del VPC consumer, questa comunicazione privata può essere tra il VPC dell'applicazione (producer) e un ambiente remoto, ad esempio un ambiente on-premise.
In questo scenario, le interfacce Private Service Connect consentono a un'istanza VM del producer di servizi di accedere alla rete di un consumer. Ciò avviene condividendo un'interfaccia di rete, pur mantenendo la separazione tra i ruoli di produttore e consumatore. Con questa interfaccia di rete nel VPC consumer, la VM dell'applicazione può accedere alle risorse consumer come se si trovassero localmente nel VPC del producer.
Un'interfaccia Private Service Connect è un'interfaccia di rete collegata al VPC consumer (di transito). È possibile raggiungere destinazioni esterne raggiungibili dal VPC consumer (di transito) a cui è collegata l'interfaccia Private Service Connect. Pertanto, questa connessione può essere estesa a un ambiente esterno tramite una connettività ibrida come un ambiente on-premise, come illustrato nel diagramma seguente:
Se il VPC consumer è un'organizzazione o un'entità esterna, come un'organizzazione di terze parti, in genere non avrai la possibilità di proteggere la comunicazione con l'interfaccia Private Service Connect nel VPC consumer. In questo scenario, è possibile definire criteri di sicurezza nel sistema operativo guest della VM di interfaccia Private Service Connect. Per maggiori informazioni, consulta Configurare la sicurezza per le interfacce di Private Service Connect. Puoi anche prendere in considerazione un approccio alternativo se non è conforme agli standard o alla conformità di sicurezza della tua organizzazione.
Best practice
Per le situazioni in cui le richieste del client da internet devono essere ricevute localmente da un frontend ospitato in un ambiente privato on-premise o in un altro ambiente cloud, valuta la possibilità di utilizzare la soluzione ibrida come gateway API.
- Questo approccio facilita anche la migrazione della soluzione in un ambiente completamente ospitato da Google Cloud, mantenendo al contempo la coerenza della piattaforma API (Apigee).
Per ridurre al minimo la latenza e ottimizzare i costi per volumi elevati di trasferimenti di dati in uscita in altri ambienti quando questi ambienti sono in 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 a livello di frontend di destinazione nell'ambiente appropriato, utilizza la modalità ibrida.
Ove applicabile ai tuoi requisiti e all'architettura, utilizza Apigee Adapter per Envoy con un deployment ibrido con Kubernetes.
Prima di progettare la connettività e i percorsi di routing, devi identificare le richieste API o di traffico da indirizzare a un gateway API locale o remoto, oltre agli ambienti di origine e di destinazione.
Utilizza Controlli di servizio VPC per proteggere i servizi Google Cloud nei progetti e ridurre il rischio di esfiltrazione di dati specificando i perimetri di servizio a livello di progetto o di rete VPC.
- Puoi estendere i perimetri di servizio a un ambiente ibrido su una VPN autorizzata o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta Panoramica dei Controlli di servizio VPC.
Utilizza le regole firewall Virtual Private Cloud (VPC) o i criteri firewall per controllare l'accesso a livello di rete alle risorse di 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 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 ed esporlo alla rete internet pubblica.
- 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 ibridi e multi-cloud.