In today’s digital age, businesses rely heavily on cloud computing infrastructure to enable efficient and scalable operations. Google Cloud Platform offers a powerful set of tools to manage and deploy virtual machines (VMs) across a distributed network. However, ensuring the security and seamless intercommunication of these VMs can be challenging. In this article, we will explore how to enable intercommunication of distributed Google Virtual Machines via a secured private network, providing a solution to this problem.
Let’s take a closer look at the current situation. One of our clients requested multitenant support for their newly launched application(s), which enables all of their customers’ sentiments to be converted from text to speech, for their end users. The real difficulty lay in connecting the various services found in various VPCs while providing multitenant support for the customers who were spread out geographically. At first, we thought VPC peering might be the best way to connect multiple VPC that are in different regions, but we later discovered the main challenges with the peering, which are:
After researching, we identified Private Service Connect (PSC)is the enabler, for a quicker solution. The same has been communicated to the Client Team and the solution has been implemented in the Client Environment.
The illustration below demonstrates how Private Service Connect routes traffic to managed services, such as Google APIs and published services, by allowing traffic to endpoints and backends.
Google Cloud networking provides Private Service Connect, which enables users to access manage services privately within their VPC network. Moreover, this feature enables managed service providers to host these services in their individual VPC and provide private connection to their users.
By this way the users can access the services using their internal IP addresses, eliminating the need to leave their VPC networks or use external IP addresses where all the traffic remains within Google Cloud granting precise control over the way services are accessed.
Managed services of various types are supported by Private Service Connect, including the following:
Private Service Connect facilitates Private connectivity has salient features, such as:
1. Create a new project- shared-resource-vpc to maintain Redis as centralized service across multiple projects
2. VPC Creation: A new VPC named lb-vpc created in the US-West region
For instance, assuming all the customers of the client use the default IP range of 10.0.3.0/24. To avoid an overlapping ip, created a new subnet (lb-lb-west) with the range 10.0.4.0/24 in the shared-resource-vpc project. The subnet is created in the US-West region assuming all the VM in the project is present in the West region, this is because Private service connect only allows inter-region connections, whereas VPC peering allows multi- region connection.
3. Redis is created in the Standard mode under the shared-resource-VPC project using the lb-vpc along with securities like Auth and TLS enabled.
4. A new VM is created in the shared-resource-VPC project, and installed HA Proxy to route traffic of the Redis machine
5. Internal Load balancer is used to manage the service connection across the project, new TCP LB created in the Shared-resource-VPC project named lb-west.
Configured the backend with 6378 ports enabled to communicate with the proxy machine and the frontend machine used to forward the rule with an Ip.
6. Private service Connect is used to configure the Publisher and the receiver connection, in our case the publisher is the shared-resource-VPC and the receiver is the Kansas-dev-18950 project.
After creating the private service connect in the publisher machine the service Attachment ID has to be used in the end point connection to establish the connection between the two projects.
7. Testing the connection from the foundry2 machine to Redis memory store present in the Kansas-dev project, we now use the private service endpoint to connect to the Redis machine along with TLS certificate attached in the foundry2 VM.
PSC brings in a plethora of benefits to the customers who have heavy customer base at disparate locations.
Are you still not sure on how to Secure your distributed Google Virtual Machines by enabling intercommunication via a private network? Contact us we are here to help you.
In conclusion, the secure intercommunication of distributed Google Virtual Machines via a private network is a crucial step in ensuring the efficient and scalable operation of cloud computing infrastructure. With the right tools and best practices in place, businesses can take advantage of the power of Google Cloud Platform while ensuring the security of their data and operations. By following the guidelines provided in this article, organizations can confidently deploy and manage their virtual machines across a distributed network, achieving seamless intercommunication and network security.
By Uma Raj
By Kavitha V Amara