Calling a private Google Cloud Function from on-prem
Many enterprise customers come to Google Cloud Professional Services asking how they can invoke a Google Cloud Function from their on-prem servers in a private way, without exposing it to the internet.
For security reasons they don’t want to have a public endpoint for their Cloud Functions (even if it would be possible to require authentication), but it’s required that network traffic remains on customer’s on-prem and GCP private network.
While creating a new Cloud Function you can set connections ingress settings to only allow internal traffic, but if we read the documentation page carefully it says: “Only requests from VPC networks in the same project or VPC Service Controls perimeter are allowed. All other requests are denied with a 403 error.” This means we’re still not able to invoke our Function from a project that’s not the same project where it’s deployed to.
Private Service Connect to the rescue
Private Service Connect (PSC) allows you to access Google Cloud services via an endpoint that you create inside a VPC network of your project containing the Cloud Function.
Instead of sending API requests to the publicly available IP addresses for service endpoints such as storage.googleapis.com, you can send the requests to the internal IP address of this Private Service Connect endpoint. All the calls flowing through this endpoint will behave as if they were made from within the same project.
Please be aware that this endpoint will allow you to reach any Google service, so you should put firewall rules in place to disallow this behavior for those hosts that shouldn’t get access.
Complete the design with some DNS and routing
Now that the Private Service Connect endpoint is ready to accept requests you have to somehow send all the Cloud Function call requests from on-prem to this IP address.
To do so you have to configure the on-prem DNS in a way that each call to the Cloud Function subdomain for your specific project ends up resolving to the endpoint you just created.
Each HTTP Cloud Function you create (even the private ones) will have a URL in the format https://YOUR_REGION-YOUR_PROJECT_ID.cloudfunctions.net/FUNCTION_NAME.
This means you have to create an entry in your on-prem DNS to translate the YOUR_REGION-YOUR_PROJECT_ID.cloudfunctions.net subdomain to point to the Private Service Connect endpoint.
The only thing left to do is routing the traffic to the Private Service Connect endpoint. Frequently the on-prem environment will be connected to Google Cloud via HA VPN or Cloud Interconnect. These connectivity methods involve the use of a Cloud Router to establish a BGP session between Google Cloud and your on-prem environment. Leveraging this BGP session we can advertise the IP address of the Private Service Connect endpoint to the on-prem.
Show me some code!
Since an example is worth a thousand words I’ve put together a Terraform demo that can be used to play around with the scenario I just described. You can find the repository on GitHub: https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/examples/networking/private-cloud-function-from-onprem
Wrap-up
In this post we have seen how to call a private Google Cloud Function from anywhere within your private network.
- Private Cloud Functions can only be invoked by resources within the same Google Cloud project.
- Private Service Connect is a convenient way to access Google Cloud services via private endpoints and we can leverage this to invoke private Cloud Functions.
- DNS and routing are the bread and butter of any network architecture and we took advantage of those to route traffic from on-prem to the Private Service Connect endpoint.
