Google Private Service Connect for secure multi-tenant design

Private Service Connect (PSC) in Google Cloud Platform (GCP) allows private consumption of services across networks and projects, teams or even organizations. Private Service Connect has the following three major options:

• Allows creating private endpoints to Google APIs using global internal IP addresses within your VPC network. This enables creation of custom Internal DNS names and IP addresses that allow traffic from your GCP or On-premise systems to reach Google APIs without routing over the internet.
• Private Service Connect endpoints with consumer HTTP(S) service controls can be created using an internal HTTP(S) load balancer. This allows for renaming API URLs, filtering URLs by path, custom certificates and logging.
• Private Service Connect lets a service “Producer” offer services to a service “Consumer”. A service producer VPC network can support multiple service consumers. This can be done using Internal IP forwarding rules, or based on a Global HTTPS load balancer.

This article will focus on the last of the above scenarios of segregating multiple client resources in different GCP projects and providing access to it through a single web interface. This shows how resources can be separated in Networking and Identity and Access Management (IAM) controls, yet being made accessible through a single unified access.

This example scenario was done to implement a Virtual Desktop Interface (VDI) solution using Apache Guacamole server and Compute Engine virtual machines. Machines for different customers are provisioned in independent projects with standalone VPC networks, and Guacamole service instances. Client specific URLs are used to access the VDI over the Internet handled by the Global load balancer.

Here is a component view of the design.

Global Load Balancer

Multiple public URLs are directed to the GLB front end IP address and appropriate wild card certificates are assigned — for example, customer1.vdi.example.com, customer2.vdi.example.com etc.

Private Service Connect Network Endpoint Groups

The Load Balancer is configured with multiple Network Endpoint Group (PSC NEG) back-ends, which attaches to Private Service Connect Endpoints (PSC EP).

The Load balancer consults a URL map to direct traffic to the appropriate NEG back-end based on the incoming request URL.

Private Services (SVC) and Endpoints (EP)

Each endpoint is an authorized connection to a corresponding Private Service Connect published service from the customer (Producer) project.

TCP Internal Load Balancer

A TCP Internal load balancer on port 443 is published as a PSC Service with multiple back-end instances providing the service (Guacamole server in this example).

The following logical design diagram shows the GCP deployment details.

Key Considerations

• When a PSC service is published on the Producer (green) projects, there is an available option to accept connections from any projects, or to specify individual projects. This option should be set up to accept connections from the Public Access (blue) project only — example screenshot below:

• The Published service must use a TCP Internal Load Balancer that accepts HTTPS traffic. This is an important requirement. The Google documentation for PSC states that that this is the only supported configuration for a Service that is used with a Global Load balancer for public access. If the internal load balancer is configured instead with HTTPS, the PSC endpoint will still show an established connection, but the traffic hitting the Global Load balancer external URL/IP will not pass through to the PSC back-end service.
• PSC masks the underlying network structure and publishes the service via an End Point, associated with an internal IP in the consumer VPC. This means you could have overlapping IP ranges in the individual Producer VPCs and/or the Consumer VPCs and the traffic flow would still work seamlessly.

Thanks for reading, and ping me here with any questions.