Accesso privato ai servizi in reti sovrapposte su Google Cloud

gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash


Creare un managed instance group in 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 completata la creazione, il managed instance group avvia un'istanza nella zona target.
Collegarsi all'istanza via SSH e verificare lo stato del servizio nginx.




Creare un'istanza per il test di connettività in 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 di Project A e Project B non hanno alcuna connettività interna: l'istanza in Project A non può quindi raggiungere il servizio in esecuzione in Project B.
Il VPC peering non è ammesso a causa della sovrapposizione di intervalli nella rete predefinita.
Configurare il load balancer interno
Per esporre il servizio tramite service attachment, Private Service Connect richiede un load balancer interno. Per questa configurazione creiamo un load balancer TCP interno in Project B.

Creare un nuovo health check HTTP regionale per testare la connettività HTTP delle 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 producer
Pubblicare il servizio in Project B, ovvero il progetto producer, per permettere ai consumer in altre reti VPC di connettersi e accedere al servizio in modo privato e sicuro.

Riservare una subnet per Private Service Connect. L'intervallo di questa subnet non deve sovrapporsi alla 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 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
L'elenco dei consumer autorizzati ad accedere ai servizi pubblicati può essere gestito tramite approvazione automatica o manuale. Per i dettagli, consultare Publish services by using Private Service Connect.

Configurare una regola firewall che consenta a Private Service Connect di raggiungere le istanze target.

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 consumer
Un endpoint nel progetto consumer si collega ai servizi della rete VPC del producer tramite una forwarding rule di Private Service Connect.
Alla creazione, l'endpoint viene registrato automaticamente in Service Directory, in un namespace scelto dall'utente o in quello predefinito, goog-psc-default.
Per rendere l'endpoint disponibile in 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 di 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


Verificare la connettività dal progetto consumer
I componenti di Private Service Connect sono ora configurati in Project A e in Project B. Utilizzare l'IP dell'endpoint in Project A per raggiungere il servizio nginx in Project B.
Il test conferma che le istanze nelle reti sovrapposte possono 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 tra reti sovrapposte.
Il traffico resta interamente all'interno di Google Cloud, con un accesso ai servizi tra consumer e producer governato da un controllo granulare sulle modalità di utilizzo.
Per approfondire Private Service Connect, consultare la pagina dedicata al prodotto.
\n'yum\ install\ epel-release


Creare un managed instance group in Project B.

Una volta completata la creazione, il managed instance group avvia un'istanza nella zona target.
Collegarsi all'istanza via SSH e verificare lo stato del servizio nginx.




Creare un'istanza per il test di connettività in Project A.


Le reti di Project A e Project B non hanno alcuna connettività interna: l'istanza in Project A non può quindi raggiungere il servizio in esecuzione in Project B.
Il VPC peering non è ammesso a causa della sovrapposizione di intervalli nella rete predefinita.
Configurare il load balancer interno
Per esporre il servizio tramite service attachment, Private Service Connect richiede un load balancer interno. Per questa configurazione creiamo un load balancer TCP interno in Project B.

Creare un nuovo health check HTTP regionale per testare la connettività HTTP delle VM sulla porta 80.


Creare il backend service per il traffico HTTP.


Aggiungere l'instance group del servizio nginx al backend service.


Creare una forwarding rule per il backend service.


Configurare una regola firewall che consenta gli health check del load balancer.



Pubblicare i servizi nel progetto producer
Pubblicare il servizio in Project B, ovvero il progetto producer, per permettere ai consumer in altre reti VPC di connettersi e accedere al servizio in modo privato e sicuro.

Riservare una subnet per Private Service Connect. L'intervallo di questa subnet non deve sovrapporsi alla rete predefinita.


Pubblicare il servizio nginx verso Project A con approvazione esplicita del progetto.

L'elenco dei consumer autorizzati ad accedere ai servizi pubblicati può essere gestito tramite approvazione automatica o manuale. Per i dettagli, consultare Publish services by using Private Service Connect.

Configurare una regola firewall che consenta a Private Service Connect di raggiungere le istanze target.



Configurare l'endpoint nel progetto consumer
Un endpoint nel progetto consumer si collega ai servizi della rete VPC del producer tramite una forwarding rule di Private Service Connect.
Alla creazione, l'endpoint viene registrato automaticamente in Service Directory, in un namespace scelto dall'utente o in quello predefinito, goog-psc-default.
Per rendere l'endpoint disponibile in più di una regione, attivare il global access. Il global access è in Preview.

Riservare un indirizzo IP interno da assegnare all'endpoint.


Creare una forwarding rule per collegare l'endpoint al service attachment di Project B.



Verificare la connettività dal progetto consumer
I componenti di Private Service Connect sono ora configurati in Project A e in Project B. Utilizzare l'IP dell'endpoint in Project A per raggiungere il servizio nginx in Project B.
Il test conferma che le istanze nelle reti sovrapposte possono 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 tra reti sovrapposte.
Il traffico resta interamente all'interno di Google Cloud, con un accesso ai servizi tra consumer e producer governato da un controllo granulare sulle modalità di utilizzo.
Per approfondire Private Service Connect, consultare la pagina dedicata al prodotto.
\n'yum\ -y\ install\ nginx


Creare un managed instance group in Project B.

Una volta completata la creazione, il managed instance group avvia un'istanza nella zona target.
Collegarsi all'istanza via SSH e verificare lo stato del servizio nginx.




Creare un'istanza per il test di connettività in Project A.


Le reti di Project A e Project B non hanno alcuna connettività interna: l'istanza in Project A non può quindi raggiungere il servizio in esecuzione in Project B.
Il VPC peering non è ammesso a causa della sovrapposizione di intervalli nella rete predefinita.
Configurare il load balancer interno
Per esporre il servizio tramite service attachment, Private Service Connect richiede un load balancer interno. Per questa configurazione creiamo un load balancer TCP interno in Project B.

Creare un nuovo health check HTTP regionale per testare la connettività HTTP delle VM sulla porta 80.


Creare il backend service per il traffico HTTP.


Aggiungere l'instance group del servizio nginx al backend service.


Creare una forwarding rule per il backend service.


Configurare una regola firewall che consenta gli health check del load balancer.



Pubblicare i servizi nel progetto producer
Pubblicare il servizio in Project B, ovvero il progetto producer, per permettere ai consumer in altre reti VPC di connettersi e accedere al servizio in modo privato e sicuro.

Riservare una subnet per Private Service Connect. L'intervallo di questa subnet non deve sovrapporsi alla rete predefinita.


Pubblicare il servizio nginx verso Project A con approvazione esplicita del progetto.

L'elenco dei consumer autorizzati ad accedere ai servizi pubblicati può essere gestito tramite approvazione automatica o manuale. Per i dettagli, consultare Publish services by using Private Service Connect.

Configurare una regola firewall che consenta a Private Service Connect di raggiungere le istanze target.



Configurare l'endpoint nel progetto consumer
Un endpoint nel progetto consumer si collega ai servizi della rete VPC del producer tramite una forwarding rule di Private Service Connect.
Alla creazione, l'endpoint viene registrato automaticamente in Service Directory, in un namespace scelto dall'utente o in quello predefinito, goog-psc-default.
Per rendere l'endpoint disponibile in più di una regione, attivare il global access. Il global access è in Preview.

Riservare un indirizzo IP interno da assegnare all'endpoint.


Creare una forwarding rule per collegare l'endpoint al service attachment di Project B.



Verificare la connettività dal progetto consumer
I componenti di Private Service Connect sono ora configurati in Project A e in Project B. Utilizzare l'IP dell'endpoint in Project A per raggiungere il servizio nginx in Project B.
Il test conferma che le istanze nelle reti sovrapposte possono 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 tra reti sovrapposte.
Il traffico resta interamente all'interno di Google Cloud, con un accesso ai servizi tra consumer e producer governato da un controllo granulare sulle modalità di utilizzo.
Per approfondire Private Service Connect, consultare la pagina dedicata al prodotto.
\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