Il pattern Uscita controllata e ingresso controllato utilizza una combinazione di uscite controllate e ingressi controllati 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 ambienti on-premise privati o in altri ambienti cloud. In questo pattern, puoi utilizzare gateway API, endpoint Private Service Connect o bilanciatori del carico per esporre API specifiche e, facoltativamente, fornire autenticazione, autorizzazione e controlli delle chiamate API.
La differenza principale tra questo pattern e il pattern a maglia sta nella sua applicazione a scenari che richiedono solo l'utilizzo di API bidirezionali 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 ad indirizzi IP specifici, le reti degli ambienti non devono essere allineate nel design. Gli scenari applicabili comuni 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 indirizzi IP di destinazione specifici) utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi di cui è stato eseguito il deployment nell'ambiente di calcolo privato.
- Al contrario, i carichi di lavoro di cui esegui il deployment in altri ambienti di calcolo possono comunicare con il gateway API lato Google Cloud(o con un indirizzo IP dell'endpoint pubblicato specifico) utilizzando indirizzi IP interni. Non è possibile raggiungere altri sistemi di 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 include i seguenti elementi:
- D'altra parte, puoi eseguire il deployment dei carichi di lavoro in un VPC (o in un VPC condiviso) senza esporli direttamente a internet. Google Cloud
- La Google Cloud rete dell'ambiente 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 multicloud adatto per facilitare la comunicazione tra gli ambienti in modo che possano utilizzare gli indirizzi IP interni.
- Se vuoi, puoi attivare l'accesso ad indirizzi IP di destinazione specifici per utilizzare una VPC di transito e aggiungere un livello di sicurezza perimetrale all'esterno della 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.
- Per accedere alle API è necessario utilizzare un API Gateway o un bilanciatore del carico per fornire un livello proxy e un'astrazione o una facciata 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 sovrapposizioni.
Un'applicazione comune di questo pattern prevede il deployment dei backend delle applicazioni (o di un sottoinsieme di backend delle applicazioni) in Google Cloud e l'hosting di altri componenti frontend e backend in ambienti on-premise o in altri cloud (pattern ibrido a più livelli o pattern multicloud 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 provider cloud. Inoltre, alcune 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à della connettività multicloud e ibrida di Cloud Load Balancing esterno possono essere utilizzate per terminare le richieste degli utenti e inoltrarle a frontend o backend in altri ambienti. Questo routing avviene tramite una connessione di rete ibrida, come illustrato nel seguente diagramma. Questa integrazione consente la distribuzione graduale dei componenti dell'applicazione in ambienti diversi. Le richieste dal frontend ai servizi di backend ospitati in Google Cloud comunicano in modo sicuro tramite la connessione di rete ibrida stabilita grazie a un bilanciatore del carico interno (ILB nel diagramma).
L'utilizzo del Google Cloud design nel diagramma precedente è utile per quanto segue:
- Facilita la comunicazione bidirezionale tra Google Cloud, ambiente 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 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 point of presence (PoP) distribuiti:
- Riduci le spese in conto capitale e semplifica le operazioni utilizzando i servizi gestiti serverless.
- Ottimizza le connessioni ai backend delle applicazioni a livello globale per velocità
e latenza.
- Google Cloud Cross-Cloud Network 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.
- Se vuoi, puoi incorporare Private Service Connect nel tuo design. In questo modo, viene attivato un accesso privato e granulare alle API di servizio o ai tuoi servizi pubblicati da altri ambienti senza attraversare internet pubblico. Google Cloud
Varianti
I pattern di architettura con uscita e ingresso controllati possono essere combinati con altri approcci per soddisfare diversi requisiti di progettazione, tenendo comunque conto dei requisiti di comunicazione di questo pattern. I pattern offrono le seguenti opzioni:
- Gateway API distribuiti
- Comunicazione bidirezionale dell'API tramite Private Service Connect
- Comunicazione bidirezionale mediante endpoint e interfacce Private Service Connect
Gateway API distribuiti
In scenari come quello basato sul pattern multicloud partizionato, le applicazioni (o i componenti dell'applicazione) possono essere create in diversi ambienti cloud, incluso un ambiente on-premise privato. 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 API gateway. Queste applicazioni e i relativi componenti potrebbero richiedere anche funzionalità specifiche della piattaforma API per l'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 contribuisce a 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 di 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 API e i proxy all'interno di ogni ambiente gestiscono le richieste API di client e applicazioni in direzioni diverse in più ambienti.
- La funzionalità API Gateway in Google Cloud (Apigee) espone i componenti dell'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 prendere in considerazione l'utilizzo di una VPC di transito. Una VPC di transito può offrire la flessibilità di separare i problemi ed eseguire ispezioni di sicurezza e connettività ibrida in una rete VPC separata. Dal punto di vista della raggiungibilità degli indirizzi IP, un VPC di transito (a cui è collegata la connettività ibrida) soddisfa i seguenti requisiti per mantenere la raggiungibilità end-to-end:
- Gli indirizzi IP per le API target devono essere pubblicizzati negli altri ambienti in cui sono ospitati i client/richiedenti.
- Gli indirizzi IP degli host che devono comunicare con le API di destinazione devono essere pubblicizzati nell'ambiente in cui risiede l'API di destinazione, ad esempio gli indirizzi IP dell'autore della richiesta dell'API (il client). L'eccezione si verifica quando la comunicazione avviene tramite un bilanciatore del carico, un proxy, un endpoint Private Service Connect o un'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 richieste API specifiche provenienti da carichi di lavoro ospitati all'interno del VPC dell' Google Cloud applicazione tramite il VPC di transito. In alternativa, puoi utilizzare un endpoint Private Service Connect nella VPC dell'applicazione associata a un bilanciatore del carico con un backend del gruppo di endpoint di rete ibrida nella VPC di transito. Questa configurazione è descritta nella sezione successiva: Comunicazione API bidirezionale tramite Private Service Connect.
Comunicazione bidirezionale delle API tramite Private Service Connect
A volte le aziende potrebbero non dover utilizzare immediatamente un gateway API (come Apigee) o potrebbero 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 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 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 in più regioni e tramite 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 di assemblare le applicazioni in ambienti multi-cloud e on-premise. In questo modo è possibile soddisfare diversi requisiti di comunicazione, ad esempio integrare applicazioni sicure in cui non viene utilizzato o non è previsto l'utilizzo di un gateway API.
Utilizzando Private Service Connect con Cloud Load Balancing, come mostrato nel seguente diagramma, puoi ottenere due percorsi di comunicazione distinti. Ogni percorso viene avviato da una direzione diversa per uno scopo di connettività distinto, idealmente tramite 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à mostrati nel diagramma precedente rappresentano connessioni indipendenti e non illustrano la comunicazione bidirezionale di una singola connessione o flusso.
Comunicazione bidirezionale mediante endpoint e interfacce Private Service Connect
Come discusso nel pattern di ingresso controllato, una delle opzioni per abilitare la comunicazione client-service è utilizzare un endpoint Private Service Connect per esporre un servizio in un VPC di produzione a un VPC di consumo. Questa connettività può essere estesa a un ambiente on-premise o persino a un altro ambiente di provider cloud tramite una connettività ibrida. Tuttavia, in alcuni scenari, il servizio ospitato può richiedere anche la 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 consumer, questa comunicazione privata può avvenire 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 di un producer di servizi di accedere alla rete di un consumer. Lo fa condividendo un'interfaccia di rete, mantenendo al contempo la separazione dei ruoli di produttore e consumatore. Con questa interfaccia di rete nel VPC consumer, la VM dell'applicazione può accedere alle risorse del consumer come se si trovassero localmente nel VPC del producer.
Un'interfaccia Private Service Connect è un'interfaccia di rete collegata alla 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, ad esempio un ambiente on-premise, come illustrato nel seguente diagramma:
Se il VPC consumer è un'organizzazione o un'entità esterna, come un'organizzazione di terze parti, in genere non potrai proteggere la comunicazione con l'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. In alternativa, puoi prendere in considerazione un approccio diverso se non è conforme alle norme o alla conformità alla sicurezza della tua organizzazione.
Best practice
Per le situazioni in cui le richieste dei client provenienti da internet devono essere ricevute localmente da un frontend ospitato in un ambiente cloud on-premise privato o di altro tipo, valuta la possibilità di utilizzare Hybrid come soluzione di gateway API.
- Questo approccio facilita anche la migrazione della soluzione a un ambiente Google Cloudcompletamente ospitato, mantenendo 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 verso gli altri ambienti quando questi sono in configurazioni ibride o multicloud permanenti o a lungo termine, tieni presente quanto segue:
- Utilizza Cloud Interconnect o Cross-Cloud Interconnect.
- Per terminare le connessioni utente nel frontend di destinazione nell'ambiente appropriato, utilizza Hybrid.
Se applicabile ai tuoi requisiti e all'architettura, utilizza Apigee Adapter 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 Google Cloud servizi nei tuoi progetti e per 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 tramite una VPN autorizzata o Cloud Interconnect. Per ulteriori informazioni sui vantaggi dei perimetri di servizio, consulta la 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, le regole firewall in uscita nel VPC dell'applicazione (consumatore) 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 workload in una subnet privata richiede l'accesso a internet, utilizza Cloud NAT per evitare di assegnare un indirizzo IP esterno al workload e di esporlo all'internet pubblico.
- 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 ibrida e multicloud.