Looker PSC Northbound Regional Internal L7 ALB

About this codelab

47 minutes

Last updated April 2, 2025

Written by Deepak Michael

1. Introduction

NOTE:

• Looker supports Southbound Producers in any region
• Northbound access to Looker requires the consumer VPC allowlisted to the Looker PSC instance at the time of creation or at a later interval
• Northbound access requires the Consumer PSC NEG & proxy-only subnet deployed in the same region as the Looker PSC instance.

In this codelab you will create a L7 Regional Internal Application Load Balancer & Private Service Connect Backend to gain northbound access to Looker. Northbound access to Looker requires the Consumer VPC allowlisted to the Looker PSC instance.

Private Service Connect is a capability of Google Cloud networking that allows consumers to access managed services privately from inside their VPC network. Similarly, it allows managed service producers to host these services in their own separate VPC networks and offer a private connection to their consumers. For example, when you use Private Service Connect to access Looker, you are the service consumer, and Google is the service producer, as highlighted in Figure 1.

Figure 1.

Southbound access, also known as reverse PSC, enables the Consumer to create a Published Service as a Producer to allow Looker access to endpoints on-premises, in a VPC, to managed services and the Internet. Southbound connections can be deployed in any region, irrespective of where Looker PSC is deployed, as highlighted in Figure 2.

Figure 2.

What you'll learn

• Network requirements
• Update Looker allowlist for northbound access
• Create a Private Service Connect backend in the Consumer VPC
• Google vs. Self Signed certificates

What you'll need

• Google Cloud Project with Owner permissions
• Registered Domain
• Existing Looker PSC Instance

2. What you'll build

You'll establish an allowlisted Consumer network, looker-psc-demo, to deploy an regional internal L7 application load balancer and PSC backend NEG that requires a Google or self-managed certificate, for more detail view the load balancer and certificate summary page.

3. Network requirements

Below is the breakdown of network requirements:

Components	Description
VPC (looker-psc-demo)	Custom mode VPC
PSC NEG Subnet	Used to allocate an IP address for the Network Endpoint Group
Proxy Only Subnet	Each of the load balancer's proxies is assigned an internal IP address. Packets sent from a proxy to a backend VM or endpoint has a source IP address from the proxy-only subnet.
Backend Service	A backend service acts as a bridge between your load balancer and your backend resources. In the tutorial, the backend service is associated with the PSC NEG.

4. Codelab topology

5. Setup and Requirements

Self-paced environment setup

1. Sign-in to the Google Cloud Console and create a new project or reuse an existing one. If you don't already have a Gmail or Google Workspace account, you must create one.

• The Project name is the display name for this project's participants. It is a character string not used by Google APIs. You can always update it.
• The Project ID is unique across all Google Cloud projects and is immutable (cannot be changed after it has been set). The Cloud Console auto-generates a unique string; usually you don't care what it is. In most codelabs, you'll need to reference your Project ID (typically identified as PROJECT_ID). If you don't like the generated ID, you might generate another random one. Alternatively, you can try your own, and see if it's available. It can't be changed after this step and remains for the duration of the project.
• For your information, there is a third value, a Project Number, which some APIs use. Learn more about all three of these values in the documentation.

Caution: A project ID is globally unique and can't be used by anyone else after you've selected it. You are the only user of that ID. Even if a project is deleted, the ID can't be used again

Note: If you use a Gmail account, you can leave the default location set to No organization. If you use a Google Workspace account, choose a location that makes sense for your organization.

2. Next, you'll need to enable billing in the Cloud Console to use Cloud resources/APIs. Running through this codelab won't cost much, if anything at all. To shut down resources to avoid incurring billing beyond this tutorial, you can delete the resources you created or delete the project. New Google Cloud users are eligible for the $300 USD Free Trial program.

Start Cloud Shell

While Google Cloud can be operated remotely from your laptop, in this codelab you will be using Google Cloud Shell, a command line environment running in the Cloud.

From the Google Cloud Console, click the Cloud Shell icon on the top right toolbar:

It should only take a few moments to provision and connect to the environment. When it is finished, you should see something like this:

This virtual machine is loaded with all the development tools you'll need. It offers a persistent 5GB home directory, and runs on Google Cloud, greatly enhancing network performance and authentication. All of your work in this codelab can be done within a browser. You do not need to install anything.

6. Before you begin

Enable APIs

Inside Cloud Shell, make sure that your project id is set up:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
echo $project
echo $region

Enable all necessary services:

gcloud services enable compute.googleapis.com

7. Consumer network

In the following section, you'll create the consumer networking that will be updated in the Looker PSC VPC allowlist.

VPC Network

Inside Cloud Shell, perform the following:

gcloud compute networks create looker-psc-demo --subnet-mode custom

NOTE: Northbound access requires the consumer PSC NEG & proxy only subnet deployed in the same region as the Looker PSC instance.

Create Subnets

Inside Cloud Shell, create the consumer network endpoint group subnet:

gcloud compute networks subnets create consumer-psc-neg-subnet --network looker-psc-demo --range 172.16.30.0/28 --region $region --enable-private-ip-google-access

Inside Cloud Shell, create the internal application load balancer subnet:

gcloud compute networks subnets create consumer-ilb-subnet --network looker-psc-demo --range 172.16.40.0/28 --region $region --enable-private-ip-google-access

Inside Cloud Shell, create the producer regional proxy only subnet:

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=looker-psc-demo \
  --range=10.10.10.0/24

8. Create a Custom Domain

NOTE: You're Looker PSC Instance needs to be enabled before proceeding.

The Looker custom domain must match your private DNS subdomain e.g looker.cosmopup.com is your public DNS record and Looker custom domain.

The following steps are required to establish a custom domain:

• Create a custom domain
• Update OAuth credentials

In the example below, looker.cosmopup.com is the custom domain

OAuth example

Below is an example of OAuth credentials for Authorized origins and callback for the subdomain looker.cosmopup.com.

9. Certificates

NOTE: Certificate creation is out of scope of the tutorial

You can create either Compute Engine or Certificate Manager certificates. Use any of the following methods to create certificates using Certificate Manager:

• Regional self-managed certificates. For information about creating and using regional self-managed certificates, see deploy a regional self-managed certificate. Certificate maps are not supported.
• Regional Google-managed certificates. Certificate maps are not supported. The following types of regional Google-managed certificates are supported by Certificate Manager:
• Regional Google-managed certificates with per-project DNS authorization. For more information, see Deploy a regional Google-managed certificate.
• Regional Google-managed (private) certificates with Certificate Authority Service. For more information, see Deploy a regional Google-managed certificate with CA Service.

10. Looker VPC allowlisting

View Allowed VPCs

In the following section, you'll use Cloud Console UI to view the Looker Allowed VPCs list.

In Cloud Console, navigate to:

Looker → Looker Instance → Details

Example below, no entries are in the Allowed VPCs list:

Update Allowed VPCs

Update your Looker instance to support northbound access by adding looker-psc-demo as an Allowed VPC.

In Cloud Console, navigate to:

Looker → Looker Instance → Edit

Connections → Allowed VPCs

Ensure to select the project where looker-psc-demo is deployed followed by the VPC looker-psc-demo then Continue.

Validate Allowed VPCs

View the update Allowed VPCs list

In Cloud Console, navigate to:

Looker → Looker Instance → Details

11. Create PSC Backend

Looker PSC as a Service Producer generates a Service Attachment URI used by Service Consumers to deploy endpoints and backends to gain northbound access to Looker. In the following step, you'll identify the Looker PSC Service Attachment URI followed by creating a Private Service Connect Network Endpoint Group (NEG) backend in the Consumer VPC.

Identify the Looker PSC Service Attachment

In Cloud Console, navigate and copy the Service Attachment URI:

Looker → Looker Instance → Details

Create the PSC network endpoint group

Inside Cloud Shell, perform the following ensuring to update psc-target-service:

gcloud compute network-endpoint-groups create looker-northbound-neg \
    --network-endpoint-type=private-service-connect \
    --psc-target-service=[UPDATE WITH YOU LOOKER SERVICE ATTACHMENT URI] \
    --region=$region \
    --network=looker-psc-demo \
    --subnet=consumer-psc-neg-subnet

Example:

gcloud compute network-endpoint-groups create looker-northbound-neg \
    --network-endpoint-type=private-service-connect \
 --psc-target-service=projects/t7ec792caf2a609d1-tp/regions/us-central1/serviceAttachments/looker-psc-f51982e2-ac0d-48b1-91bb-88656971c183 \
    --region=$region \
    --network=looker-psc-demo \
    --subnet=consumer-psc-neg-subnet

Validate PSC network end group creation

Inside Cloud Shell, perform the following, ensuing the pscConnectionStatus is accepted:

gcloud compute network-endpoint-groups describe looker-northbound-neg --region=$region | grep -i pscConnectionStatus:

Example:

user@cloudshell$ gcloud compute network-endpoint-groups describe looker-northbound-neg --region=$region | grep -i pscConnectionStatus: 
  pscConnectionStatus: ACCEPTED

Create a regional Internal Application Load Balancer

In the following steps, you'll use Cloud Console to create the regional internal application load balancer while associating your generated certificates to the front end configuration.

In Cloud Console, navigate to:

Network Services → Load Balancing → Create Load Balancer

Select the following options:

Create the backend configuration

Select the following options and customize the environment based on your deployment:

• Region used in deploying the network infrastructure
• Network: looker-psc-demo
• Proxy-Only subnet is auto populated based on your region & network

Routing Rules

No configuration required

Frontend configuration

Ensure the load balancer is enabled and obtain the IP Address.

In Cloud Console → Network Services → Load Balancing → looker-ilb-alb

12. DNS resolution

DNS resolution to the custom domain can be authoritative on-premesis or Cloud DNS. In the tutorial we will define Cloud DNS as the authoritative server for the Looker Custom Domain. Enabling on-premesis to GCP DNS resolution requires the enablement of Inbound Server policies. When you create an inbound server policy, Cloud DNS creates inbound server policy entry points in the VPC network to which the server policy is applied. Inbound server policy entry points are internal IPv4 addresses sourced from the primary IPv4 address range of every subnet in the applicable VPC network, except for proxy only subnets.

In the following section, a Private DNS zone for the Looker Custom Domain, looker.cosmopup.com & A record is created consisting of the load balancer IP address.

13. Create a Private DNS Zone

Inside Cloud Shell, create the Cloud DNS Private Zone.

gcloud dns --project=$projectid managed-zones create looker-cosmopup-dns --description="" --dns-name="looker.cosmopup.com." --visibility="private" --networks="https://compute.googleapis.com/compute/v1/projects/$projectid/global/networks/looker-psc-demo"

Inside Cloud Shell, create the A record consisting of the load balancer IP Address, obtained in the earlier step.

gcloud dns --project=$projectid record-sets create looker.cosmopup.com. --zone="looker-cosmopup-dns" --type="A" --ttl="300" --rrdatas="<insert-your-ip>"

Example:

gcloud dns --project=$projectid record-sets create looker.cosmopup.com. --zone="looker-cosmopup-dns" --type="A" --ttl="300" --rrdatas="172.16.20.7"

Next, hybrid networking (e.g. Interconnect, HA-VPN) must be configured between the looker-psc-demo VPC and the on-premises network to enable connectivity.

Below are the steps required to establish Hybrid NEG connectivity to on-premesis:

• Choosing a Network Connectivity product | Google Cloud
• In a hub and spoke architecture with VPC peering, the Hybrid NEG is deployed in the same VPC as the Cloud Router (hub)
• Ensure that on-premises firewalls are updated to accommodate the proxy-only subnet range, as this subnet serves as the source IP address for communication with on-premises workloads
• Update on-premises DNS with the inbound forwarding IP Address as the DNS resolver for looker.cosomopup.com

Access the Looker UI

Now that the load balancer is operational, you can access your custom Looker domain through a web browser. It's important to note that you may encounter a warning depending on the type of certificate you're using, e.g. untrusted certificate vs. trusted.

Below is an example (untrusted certificate) of accessing the Looker custom domain looker.cosmopup.com that gains northbound access to the Looker UI:

14. Clean up

From a single Cloud Shell terminal delete lab components:

gcloud compute forwarding-rules delete regional-internal-alb-fr --region=$region -q

gcloud compute target-https-proxies delete regional-internal-alb-target-proxy --region=$region -q

gcloud compute url-maps delete regional-internal-alb --region=$region -q

gcloud compute backend-services delete looker-psc-neg-backend-svc --region=$region -q

gcloud compute addresses delete regional-alb-static-ip --region=$region -q

gcloud compute network-endpoint-groups delete looker-northbound-neg --region=$region -q

gcloud compute networks delete looker-psc-demo -q

15. Congratulations

Congratulations, you've successfully configured and validated northbound connectivity to Looker using a customer domain and regional internal application load balancer.

You made the consumer infrastructure, learned how to create a PSC NEG, custom domain, and got to know the different certificate options. So many exciting things to get you going with Looker.

Cosmopup thinks codelabs are awesome!!

What's next?

Check out some of these codelabs...

• Using Private Service Connect to publish and consume services
• Connect to on-prem services over Hybrid Networking using Private Service Connect and an internal TCP Proxy load balancer
• Access to all published Private Service Connect codelabs

Further reading & Videos

• Private Service Connect overview

Reference docs

• Use self-managed SSL certificates | Load Balancing | Google Cloud
• Deploy a regional Google-managed certificate
• Create a Private Service Connect backend | VPC | Google Cloud
• Create a Private Service Connect backend | VPC | Google Cloud
• Create a Looker (Google Cloud core) Private Service Connect instance
• How to publish a service using Private Service Connect