Accesso remoto degli sviluppatori a una VPC di Google Cloud: scegliete il percorso

Uno sviluppatore ha bisogno di una sessione SSH, di una porta di database o di un accesso ampio a una dozzina di servizi privati, e ognuna di queste richieste sembra la stessa domanda. Non lo è. Le destinazioni, i protocolli e le identità coinvolte decidono quale percorso di accesso di Google Cloud è adatto, e scegliere il più ampio per impostazione predefinita crea lavoro che non dovevate assumervi.

Annotate le destinazioni e i protocolli

Elencate gli indirizzi privati, le porte e i protocolli di cui il lavoro ha davvero bisogno, poi segnate quali identità devono essere autenticate separatamente. Una porta di database e una zona DNS privata sono requisiti diversi, e un servizio UDP esclude del tutto una delle opzioni seguenti. Un elenco scritto mostra anche ciò che non state concedendo. È la parte che i revisori chiedono.

Fatelo prima di aprire un listener. L'elenco diventa poi il test di accettazione, ed è l'unico modo affidabile per distinguere un tunnel stretto da uno ampio che funziona per caso.

IAP per pochi servizi TCP

L'inoltro TCP di Identity-Aware Proxy fornisce un tunnel autenticato verso risorse VM idonee senza esporre il servizio a internet. La forma quotidiana è gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, e una singola porta può essere inoltrata localmente con gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tre cose devono allinearsi: il chiamante necessita del ruolo di accesso al tunnel IAP, il firewall deve ammettere l'intervallo di origine IAP e la destinazione deve essere raggiungibile sull'istanza. L'autorizzazione a creare il tunnel non è una credenziale di database, un accesso SSH o una sessione RDP, quindi tenete l'autenticazione dell'applicazione dove appartiene.

L'inoltro TCP di IAP non è una VPN di livello tre. Trasporta TCP verso una destinazione scelta, non traffico IP arbitrario o UDP, e si adatta male quando un'applicazione ha bisogno di DNS privato su molti servizi.

Una VPN per l'accesso remoto per una raggiungibilità più ampia

Quando servono più destinazioni, protocolli o zone DNS private, la forma migliore è una VPN per l'accesso remoto gestita esplicitamente su una VM o un dispositivo supportato. Questa distribuzione è separata da Cloud VPN gestito da Google: possedete l'arruolamento dell'identità client, gli aggiornamenti software, le rotte del client e le rotte di ritorno della VPC.

Pianificate l'intero elenco, non solo il listener pubblico. Includete il pool di tunnel, la rotta della VPC di ritorno, i controlli di inoltro, la risoluzione DNS e la politica di accesso per servizio. Una VPN che si connette ma non riesce a risolvere i nomi interni fa fallire il flusso di lavoro dello sviluppatore altrettanto completamente di una che non si connette mai.

Cloud VPN è un gateway di sito, non un profilo per portatile

Google Cloud VPN collega gateway peer tramite IPsec, e le sue domande frequenti separano quel ruolo da sito a sito dall'accesso da client a gateway. Creare un tunnel non produce un profilo che un dipendente importa su un portatile. La distinzione conta quando qualcuno chiede un profilo Cloud VPN. La risposta è un altro prodotto.

Ciò che un gateway fa bene è dare alle macchine dietro una rete d'ufficio una rotta verso la VPC. Non autentica ogni dipendente né concede autorizzazioni applicative, quindi quelle politiche restano ai livelli di rete e applicazione, dove possono essere applicate per identità.

Verificate e registrate

Provate prima la destinazione più stretta, poi quella che richiede DNS e poi una destinazione che deve restare negata. Eseguite ogni test dallo stesso client che userà il percorso in produzione, perché un test funzionante da una postazione di amministratore dimostra poco su un portatile di sviluppatore con un'altra rete.

Registrate il modello scelto, le destinazioni che copre, le identità che autentica e il comportamento in caso di guasto quando il percorso non è disponibile. Quel registro è ciò che impedisce alla richiesta successiva di ampliare silenziosamente il tunnel invece di aggiungere una destinazione a una progettazione documentata.