Privately access services in overlapping networks in 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


Create a 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
After the successful creation, the managed instance group launches an instance in the target zone.
SSH into the instance and validate the nginx service status.




Create a connectivity test instance 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

Project A and Project B networks have no internal connectivity. So the instance in Project A cannot access the service running in Project B.
VPC peering is not allowed because of the overlapping range in the default network.
Setup Internal load balancer
An internal load balancer is required for Private Service Connect to expose the service via service attachment. We will create an internal TCP load balancer for this setup in Project B.

Create a new regional HTTP health check to test HTTP connectivity to the VMs on port 80.

gcloud compute health-checks create http nginx-service-health-check \
    --region=us-west4 \
    --port=80 \
    --project=$PROJECT_B

Create the backend service for HTTP traffic.

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

Add the nginx service instance group to the 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

Create a forwarding rule for the 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

Set up a firewall rule to allow load balancer health checks.

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


Publish services in service producer project
Publish the service in Project B, which is the service producer project to allow the consumers in other VPC networks to connect privately and securely access the service.

Reserve a subnet for Private Service Connect. This subnet range should not overlap with the default network.

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

Publish the nginx service to project A with explicit project approval.

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
You can control the list of consumers who can access the published services either via automatic approval or manual approval, Refer to Publish services by using Private Service Connect.

Set up a firewall rule to allow Private Service Connect to access the target instances.

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


Configure Endpoint in service consumer project
An endpoint in the service consumer project connects to services in the producer VPC network using a Private Service Connect forwarding rule.
When you create an endpoint, it is automatically registered with Service Directory, using a namespace that you choose or the default namespace, goog-psc-default.
To make the Endpoint available from more than one region, turn on global access. Global access is in Preview.

Reserve an internal IP address to assign to the Endpoint.

gcloud compute addresses create private-service-connect-endpoint \
    --region=us-west4 \
    --subnet=default \
    --project=$PROJECT_A

Create a forwarding rule to connect the Endpoint to the Project B service attachment.

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


Test the connectivity from Consumer Project
Private Service Connect components are now configured in Project A and Project B. Use the endpoint IP in Project A to access the nginx service in Project B.
The test confirms the instances in the overlapping can communicate privately via the Private Service Connect Endpoint.

This example illustrates how you can use Private Service Connect to securely publish and consume services in overlapping networks.
Traffic remains entirely within Google Cloud, providing service-oriented access between consumers and producers with granular control over how services are accessed.
Read more about Private Service Connect on the product page.
\n'yum\ install\ epel-release


Create a managed instance group in Project B.

After the successful creation, the managed instance group launches an instance in the target zone.
SSH into the instance and validate the nginx service status.




Create a connectivity test instance in Project A.


Project A and Project B networks have no internal connectivity. So the instance in Project A cannot access the service running in Project B.
VPC peering is not allowed because of the overlapping range in the default network.
Setup Internal load balancer
An internal load balancer is required for Private Service Connect to expose the service via service attachment. We will create an internal TCP load balancer for this setup in Project B.

Create a new regional HTTP health check to test HTTP connectivity to the VMs on port 80.


Create the backend service for HTTP traffic.


Add the nginx service instance group to the backend service.


Create a forwarding rule for the backend service.


Set up a firewall rule to allow load balancer health checks.



Publish services in service producer project
Publish the service in Project B, which is the service producer project to allow the consumers in other VPC networks to connect privately and securely access the service.

Reserve a subnet for Private Service Connect. This subnet range should not overlap with the default network.


Publish the nginx service to project A with explicit project approval.

You can control the list of consumers who can access the published services either via automatic approval or manual approval, Refer to Publish services by using Private Service Connect.

Set up a firewall rule to allow Private Service Connect to access the target instances.



Configure Endpoint in service consumer project
An endpoint in the service consumer project connects to services in the producer VPC network using a Private Service Connect forwarding rule.
When you create an endpoint, it is automatically registered with Service Directory, using a namespace that you choose or the default namespace, goog-psc-default.
To make the Endpoint available from more than one region, turn on global access. Global access is in Preview.

Reserve an internal IP address to assign to the Endpoint.


Create a forwarding rule to connect the Endpoint to the Project B service attachment.



Test the connectivity from Consumer Project
Private Service Connect components are now configured in Project A and Project B. Use the endpoint IP in Project A to access the nginx service in Project B.
The test confirms the instances in the overlapping can communicate privately via the Private Service Connect Endpoint.

This example illustrates how you can use Private Service Connect to securely publish and consume services in overlapping networks.
Traffic remains entirely within Google Cloud, providing service-oriented access between consumers and producers with granular control over how services are accessed.
Read more about Private Service Connect on the product page.
\n'yum\ -y\ install\ nginx


Create a managed instance group in Project B.

After the successful creation, the managed instance group launches an instance in the target zone.
SSH into the instance and validate the nginx service status.




Create a connectivity test instance in Project A.


Project A and Project B networks have no internal connectivity. So the instance in Project A cannot access the service running in Project B.
VPC peering is not allowed because of the overlapping range in the default network.
Setup Internal load balancer
An internal load balancer is required for Private Service Connect to expose the service via service attachment. We will create an internal TCP load balancer for this setup in Project B.

Create a new regional HTTP health check to test HTTP connectivity to the VMs on port 80.


Create the backend service for HTTP traffic.


Add the nginx service instance group to the backend service.


Create a forwarding rule for the backend service.


Set up a firewall rule to allow load balancer health checks.



Publish services in service producer project
Publish the service in Project B, which is the service producer project to allow the consumers in other VPC networks to connect privately and securely access the service.

Reserve a subnet for Private Service Connect. This subnet range should not overlap with the default network.


Publish the nginx service to project A with explicit project approval.

You can control the list of consumers who can access the published services either via automatic approval or manual approval, Refer to Publish services by using Private Service Connect.

Set up a firewall rule to allow Private Service Connect to access the target instances.



Configure Endpoint in service consumer project
An endpoint in the service consumer project connects to services in the producer VPC network using a Private Service Connect forwarding rule.
When you create an endpoint, it is automatically registered with Service Directory, using a namespace that you choose or the default namespace, goog-psc-default.
To make the Endpoint available from more than one region, turn on global access. Global access is in Preview.

Reserve an internal IP address to assign to the Endpoint.


Create a forwarding rule to connect the Endpoint to the Project B service attachment.



Test the connectivity from Consumer Project
Private Service Connect components are now configured in Project A and Project B. Use the endpoint IP in Project A to access the nginx service in Project B.
The test confirms the instances in the overlapping can communicate privately via the Private Service Connect Endpoint.

This example illustrates how you can use Private Service Connect to securely publish and consume services in overlapping networks.
Traffic remains entirely within Google Cloud, providing service-oriented access between consumers and producers with granular control over how services are accessed.
Read more about Private Service Connect on the product page.
\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