Skip to content
  • Products
    • Portfolio overview >

      Flexsave™

      Automatically manage cloud compute for optimized costs and agility

      Cloud Analytics

      Make sense of spend and chargeback to align with your business

      google cloud msp

      BigQuery Lens

      Optimize BigQuery costs with actionable recommendations and usage insights

      Spot Scaling

      Maximize AWS Spot savings and minimize disruptions for optimized scaling

      Anomaly Detection

      Autonomously identify cost spikes early, with zero configuration

      Platform overview >

      Organize your billing data for better business decisions

      Integrations >

      Connect your favorite tools to DoiT’s products

  • Services
    • Services overview >

      How we work

      Learn how we’re redefining support with our customer reliability engineering

      Stats

      View our live support and customer satisfaction statistics in real-time

      Cloud solutions

      Proven solutions to cloud complexity

      FinOps

      Learn how DoiT enables critical FinOps capabilities

      Areas of expertise

      Cloud Architecture

      Ensure your cloud architecture is future-ready and built for success

      Cloud Cost Optimization

      Identify opportunities to optimize costs and target spend for added value

      Cloud Migration

      Realize greater efficiency and innovation with successful cloud migration

      Cloud Security

      Center security in your cloud strategy to ensure ongoing efficacy and growth

      Data and Analytics

      Harness the potential of big data and analytics to gain a competitive edge

      Data Management

      Build your data practice with expert guidance tailored to your business goals

      DevOps Jump Start

      Accelerate your AWS workloads & release pipelines while also increasing automation, monitoring & reliability

      Infrastructure

      Maximize the full suite capabilities from your cloud infrastructure

      Kubernetes

      Manage the complexity of Kubernetes to enable innovation and scalability

      Location-Based Services

      Transform geolocational data into real-world, real-time intelligence

      Machine Learning

      Level-up key data with ML capabilities that accelerate innovation

      Multicloud

      Create meaningful business value with a robust multicloud strategy

      Training

      Build skills and capability across teams with certified, expert-led training

  • Partners
    • Alliances

      Proud to be an award‒winning multicloud partner to top‒tier cloud providers

      doit-together

      DoiT Together

      Enabling cloud growth and unlocking revenue through expert partnership

      ISV Go-Global

      Accelerate new customer growth and Marketplace integration on AWS and GCP

  • Resources
    • Resources hub >

      Blog

      Read the latest insights, tips and perspectives from our team of cloud experts

      Case Studies

      See how we’ve helped thousands of public cloud customers achieve their goals

      Cloud Masters Podcast

      Listen to our experts and customers share tangible tips for navigating the cloud.

      Ebooks and Guides

      Discover foundational expertise and future-ready recommendations for the cloud

      Events and Webinars

      Tech talks and interactive expert sessions delivered both virtually and in person

      GCPInstances.info

      Google Cloud Compute Engine instance comparison

      Help center

      Read documentation, product updates, and more

      Newsroom

      See what's new from DoiT in our latest news and announcements

      Trust Center

      How we focus on security, compliance, and privacy

      Videos

      Watch product demos, interviews and more from our cloud experts

  • About
    • About DoiT >

      Careers

      Browse our open positions and learn more about what it takes to be a Do’er

      Leadership

      Meet the team leading DoiT and our customers on a journey of hypergrowth

      Newsroom

      See what's new from DoiT in our latest news and announcements

  • Pricing
  • Contact us
  • Sign In
  • Products
    • Flexsave ™
    • Cloud Analytics
    • Spot Scaling
    • BigQuery Lens
    • Anomaly Detection
    • DoiT Platform
    • Integrations
  • Services
    • How We Work
    • Stats
    • Cloud Solutions
    • FinOps
    • Areas of expertise
      • Cloud Architecture
      • Cloud Cost Optimization
      • Cloud Migration Consulting Services
      • Cloud Security
      • Data and Analytics
      • Data Management
      • DevOps with AWS & DoiT
      • Infrastructure
      • Kubernetes
      • Location Based Services
      • Machine Learning
      • Multicloud
      • Training
  • Partners
    • ISV Go-Global
    • Award-winning public cloud partner
    • DoiT Together
  • Resources
    • Blog
    • Case Studies
    • Cloud Masters Podcast
    • Ebooks and Guides
    • Events and Webinars
    • GCPInstances.info
    • Help center
    • Newsroom
    • Trust Center
    • Videos
  • Pricing
  • About
    • Careers
    • Leadership
    • Newsroom
  • Contact us
  • Sign In
Contact us
Sign in

Blog

Privately access services in overlapping networks in GCP

  • Chimbu Chinnadurai Chimbu Chinnadurai
  • Date: May 23, 2023
gcp-vpc

In Google Cloud Platform (GCP), each new project starts with a default VPC network when you enable the Compute Engine API Unless you disable it.

This makes your use of GCP easier since creating a custom VPC and subnets are not required. But the problem with the default network is that all the auto-created subnets use a set of predefined IPv4 ranges that fit within the 10.128.0.0/9 CIDR block.

Private internal communication is not allowed between projects because of the overlapping network. The limitation applies to both VPC Peering and Cloud VPN services.

This blog shows you how to use Private Service Connect to privately access services running in VM/GKE clusters with overlapping networks. This applies to overlapping networks in the same or different GCP organizations.

Reference Architecture

“default-vpc”

Target Private Service Connect Setup

Project B is the service producer project and a sample nginx service deployed in a managed instance group instance.

Project A is the service consumer Project, and it needs to access the service in Project B privately. The instances in both projects are not assigned with any external IP.

  • GCP Region for resources is us-west4
  • compute.googleapis.com API is enabled in Project A and Project B
  • Cloud NAT for private instance internet access to download packages

Deploy sample service and test instance

Update the variables in the commands below.

  • Create an instance template in 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

“google

  • 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.

“nginx

“gcp

“gcp

  • 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

google cloud shared vpc

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

vpc in google cloud

“google

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

“shared

“gcloud

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

vpc network gcp

“google

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.

“google

Conclusion

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.

 

 

Subscribe to updates, news and more.

Subscribe

Subscribe to updates, news and more.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Related blogs

On the money: Making DoiT Anomaly Detection more precise and personalized

With SKU-level anomaly detection and targeted anomaly alerting, you can drive a culture of responsible cloud spending while reducing the mean-time to resolve cost spike issues.

Keep reading 
7 cloud bill red flags featured

Seven not-so-obvious cloud bill red flags (and what you should do about it)

We share 7 subtle red flags in your cloud bill that may be reflective of an anti-pattern or overspending, and what you should do instead.

Keep reading 
Three steps to cost optimization culture

Three steps to establishing a cloud cost optimization culture in your company

The three foundational elements needed to build a cost optimization culture in your company — and a step by step guide to building one with DoiT’s products.

Keep reading 
View all blogs
Let’s do it

From cost optimization to cloud migration, machine learning and CloudOps, we’re here to make the public cloud easy — without the costs.

Ready to get started?

Get in touch

Company

  • About us
  • Blog
  • Careers
  • MS-HT statement
  • Newsroom
  • Privacy policy
  • Terms

Offering

  • Compliance
  • Products
  • Services
  • Solutions
  • Resources

Support

  • Sign in
  • Help center
  • Open ticket
  • Contact us

Never miss an update.

Subscribe to our newsletter

Subscribe to updates, news and more.