gRPC Service to Service on Cloud Run and Private Networking

Part 3

This is Part 3 of the article series.
Link to Part 1: gRPC service to service on Cloud Run
Link to Part 2: gRPC service to service on Cloud Run with Authentication

Wait! I’m not interested in the story, just show me the code. https://github.com/edyw/cloudrun-grpc

git clone https://github.com/edyw/cloudrun-grpc.git

Part 3: gRPC service to service on Cloud Run and Private Networking

In Part 2, we secured go-contact Cloud Run service with IAM Authorization, however the endpoint is still accessible from Internet because go-contact Cloud Run ingress is set all.

The objective is use private networking, we do not want the traffic to get out and return from the Internet. To achieve this, we set go-contact service ingress to internal.

In order for Cloud Run to reach another Cloud Run internally, we need a Serverless VPC Access connector to receive Cloud Run egress and route to the VPC network. The connector requires a dedicated /28 subnet for internal use.

In our case, egress from Cloud Run does not need to go to any services in the VPC network. So the traffic stay within a dedicated subnet for the connector, and route to target Cloud Run via Private Google Access (GPA). You need to enable GPA in the connector’s subnet configuration.

When creating the Serverless VPC Access connector, several firewall rules are automatically added, however you still need to application specific port in firewall rules in the VPC network.

With Serverless VPC Access connector, the traffic from Cloud Run can reach services in internal subnets eg. VM, GKE. However the opposite direction from services in VPC network to Cloud Run, you need to enable the subnet’s GPA.

Important: There are many ways, options, best practices to manage connectivity from Cloud Run to your private network, this is just one of them.

Now, let’s start setting up our private networking:
Step 3.1 Configure go-contact service ingress to internal only
Step 3.2 Create VPC network and a subnet for Serverless VPC Access
Step 3.3 Create Serverless VPC Access connector
Step 3.4 Configure go-api and node-api to use the connector, set VPC egress to all-traffic
Step 3.5 Test end to end

Step 3.1

Configure go-contact service ingress to internal only

In Part 2, we use deployed go-contact with default ingress, which allowed all traffic including Internet and internal. To restrict internal only traffic, we update the service with --ingress=internal:

gcloud run services update go-contact \
  --region=${REGION}
  --ingress=internal

At this stage, go-contact is no longer accessible by go-api, node-api or any clients from Internet.

Step 3.2

Create VPC network and a subnet for Serverless VPC Access

If you plan to use your existing VPC network, you need to add a dedicated subnet for Serverless VPC Access connector first, and enable Private Google Access (GPA) on your subnet.

For this article, I will create new VPC network my-corp-net and subnet sva-subnet:

gcloud compute networks create my-corp-net \
  --subnet-mode=custom

gcloud compute networks subnets create sva-subnet \
  --network=my-corp-net \
  --range=192.168.64.0/28 \
  --region=${REGION} 
  --enable-private-ip-google-access

Step 3.3

Create Serverless VPC Access connector

Let’s create the connector sva-conn using the new VPC network and subnet:

gcloud compute networks vpc-access connectors create sva-conn \
  --region=${REGION} \
  --subnet=sva-subnet

The connector is a Google Cloud managed service, internally it routes network traffic with minimum 2 VMs. You can optimize the connector with additional parameters, refer to this documentation.

There will be multiple firewall rules added together with the connector, you can verify with Google Cloud Console or CLI gcloud compute networks get-effective-firewalls my-corp-net

Step 3.4

Configure go-api and node-api to use the connector, set VPC egress to all-traffic

We have the connector ready, it can route traffic to our VPC network and to Cloud Run via GPA. Next we need to update both go-api and node-api services to use the connector sva-conn.

In addition, we need to set both Cloud Run VPC egress settings to route all-traffic to the connector too, by default it will route private-range-only which is private IP addresses (RFC1918) only. This is not what we want, because the address of go-contact service known by both services is not private IP address.

gcloud run services update go-api \
  --region=asia-southeast1 \
  --vpc-connector=sva-conn \
  --vpc-egress=all-traffic

Step 3.5

Test end to end

The diagram above shows the complete flow from client (curl) all the way to go-contact and return the result back to the client.

Finally, let’s test this out:

curl ${CLOUD_RUN_SERVICE_URL}/contact-auth/555-110022

The same previous test, we expect the output: Mike F%