Su Google Cloud Platform (GCP), ogni nuovo progetto nasce con una rete VPC predefinita nel momento in cui si abilita l'API Compute Engine, a meno che non la si disabiliti.
Questo semplifica l'utilizzo di GCP, perché non occorre creare una VPC personalizzata né le relative subnet. Il limite della rete predefinita, però, è che tutte le subnet generate automaticamente utilizzano un insieme di range IPv4 predefiniti compresi nel blocco CIDR 10.128.0.0/9.
La comunicazione interna privata tra progetti non è consentita proprio a causa della sovrapposizione delle reti. Questa limitazione vale sia per il VPC Peering sia per Cloud VPN.
In questo articolo vediamo come usare Private Service Connect per accedere in modo privato a servizi eseguiti in cluster VM/GKE con reti sovrapposte. La soluzione è valida sia per reti sovrapposte all'interno della stessa organizzazione GCP sia tra organizzazioni differenti.
Architettura di riferimento
Configurazione target di Private Service Connect
Il Project B è il progetto service producer e ospita un servizio nginx di esempio, distribuito su un'istanza che fa parte di un managed instance group.
Il Project A è il progetto service consumer e deve accedere in modo privato al servizio del Project B. Alle istanze di entrambi i progetti non è assegnato alcun IP esterno.
- La regione GCP utilizzata per le risorse è us-west4
- L'API compute.googleapis.com è abilitata sia nel Project A sia nel Project B
- Cloud NAT consente alle istanze private l'accesso a Internet per scaricare i pacchetti
Distribuire il servizio di esempio e l'istanza di test
Aggiornare le variabili nei comandi che seguono.
- Creare un instance template nel Project B.
gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash$'\n'yum\ install\ epel-release$'\n'yum\ -y\ install\ nginx$'\n'systemctl\ start\ nginx \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--reservation-affinity=any \
--project=$PROJECT_B
- Creare un managed instance group nel Project B.
gcloud beta compute instance-groups managed create nginx-service-instance-group \
--base-instance-name=nginx-service \
--size=1 \
--template=nginx-service-instance-template \
--zone=us-west4-a \
--list-managed-instances-results=PAGELESS \
--no-force-update-on-repair \
--project=$PROJECT_B
Una volta creato, il managed instance group avvia un'istanza nella zona di destinazione.
Connettersi all'istanza via SSH e verificare lo stato del servizio nginx.
- Creare un'istanza per il test di connettività nel Project A.
gcloud compute instances create instance-1 \
--zone=us-west4-b \
--machine-type=e2-medium \
--network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--labels=ec-src=vm_add-gcloud \
--reservation-affinity=any \
--project=$PROJECT_A
Le reti del Project A e del Project B non hanno alcuna connettività interna: di conseguenza, l'istanza nel Project A non può raggiungere il servizio in esecuzione nel Project B.
Il VPC peering non è praticabile a causa della sovrapposizione di range nella rete predefinita.
Configurare il load balancer interno
Per esporre il servizio tramite service attachment con Private Service Connect serve un load balancer interno. In questa configurazione creeremo un load balancer TCP interno nel Project B.
- Creare un nuovo health check HTTP regionale per verificare la connettività HTTP alle VM sulla porta 80.
gcloud compute health-checks create http nginx-service-health-check \
--region=us-west4 \
--port=80 \
--project=$PROJECT_B
- Creare il backend service per il traffico HTTP.
gcloud compute backend-services create nginx-service-internal-lb-backend \
--load-balancing-scheme=internal \
--protocol=tcp \
--region=us-west4 \
--health-checks=nginx-service-health-check \
--health-checks-region=us-west4 \
--project=$PROJECT_B
- Aggiungere l'instance group del servizio nginx al backend service.
gcloud compute backend-services add-backend nginx-service-internal-lb-backend \
--region=us-west4 \
--instance-group=nginx-service-instance-group \
--instance-group-zone=us-west4-a \
--project=$PROJECT_B
- Creare una forwarding rule per il backend service.
gcloud compute forwarding-rules create nginx-service-internal-fr \
--region=us-west4 \
--load-balancing-scheme=internal \
--network=default \
--subnet=default \
--ip-protocol=TCP \
--ports=80 \
--backend-service=nginx-service-internal-lb-backend \
--backend-service-region=us-west4 \
--project=$PROJECT_B
- Configurare una regola firewall che consenta gli health check del load balancer.
gcloud compute firewall-rules create allow-internal-lb-health-check \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=35.191.0.0/16,130.211.0.0/22
--project=$PROJECT_B
Pubblicare i servizi nel progetto service producer
Pubblicare il servizio nel Project B, ovvero il progetto service producer, per permettere ai consumer di altre reti VPC di connettersi e accedere al servizio in modo privato e sicuro.
- Riservare una subnet per Private Service Connect. Il range di questa subnet non deve sovrapporsi a quello della rete predefinita.
gcloud compute networks subnets create private-service-connect \
--network default \
--region us-west4 \
--range 10.0.1.0/24 \
--purpose=PRIVATE_SERVICE_CONNECT \
--project=$PROJECT_B
- Pubblicare il servizio nginx verso il Project A con approvazione esplicita del progetto.
gcloud compute service-attachments create nginx-service \
--region=us-west4 \
--producer-forwarding-rule=nginx-service-internal-fr \
--connection-preference=ACCEPT_MANUAL \
--nat-subnets=private-service-connect \
--consumer-accept-list=$PROJECT_A=10 \
--project=$PROJECT_B
È possibile gestire l'elenco dei consumer abilitati ad accedere ai servizi pubblicati tramite approvazione automatica o manuale. Per maggiori dettagli, si veda Pubblicare servizi con Private Service Connect.
- Configurare una regola firewall che consenta a Private Service Connect di raggiungere le istanze di destinazione.
gcloud compute firewall-rules create allow-private-service-connect \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=10.0.1.0/24
--project=$PROJECT_B
Configurare l'endpoint nel progetto service consumer
Un endpoint nel progetto service consumer si collega ai servizi della rete VPC del producer attraverso una forwarding rule di Private Service Connect.
Quando si crea un endpoint, questo viene registrato automaticamente in Service Directory, in un namespace a scelta o in quello predefinito, goog-psc-default.
Per rendere l'endpoint raggiungibile da più di una regione, attivare il global access. Il global access è in Preview.
- Riservare un indirizzo IP interno da assegnare all'endpoint.
gcloud compute addresses create private-service-connect-endpoint \
--region=us-west4 \
--subnet=default \
--project=$PROJECT_A
- Creare una forwarding rule per collegare l'endpoint al service attachment del Project B.
PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \
--region=us-west4 \
--project=$PROJECT_B \
--format="value(selfLink.scope(projects))")
gcloud compute forwarding-rules create nginx-service \
--region=us-west4 \
--network=default \
--address=private-service-connect-endpoint \
--target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \
--project=$PROJECT_A
Testare la connettività dal progetto consumer
I componenti di Private Service Connect sono ora configurati nel Project A e nel Project B. Utilizzare l'IP dell'endpoint nel Project A per accedere al servizio nginx nel Project B.
Il test conferma che le istanze nelle reti sovrapposte riescono a comunicare in modo privato attraverso l'endpoint Private Service Connect.
Questo esempio mostra come usare Private Service Connect per pubblicare e consumare servizi in modo sicuro anche in presenza di reti sovrapposte.
Il traffico resta interamente all'interno di Google Cloud e garantisce un accesso service-oriented tra consumer e producer, con un controllo granulare sulle modalità di accesso ai servizi.
Per approfondire Private Service Connect, si veda la pagina di prodotto.