Access Cloud Run with Internal Only Ingress Setting from Shared VPC
In this article, we will be discussing the ways to access cloud run service with internal only ingress setting from resources on shared VPC
Lets walkthrough setup below to understand the network and cloud run settings
Lets start with the cloud run service.
The cloud run deployed is a very basic application that returns the request data as response appended with text snippet as below
import os
from flask import Flask
from flask import request
app = Flask(__name__)
@app.route("/", methods=["POST"])
def parse_request():
request_json = request.get_json()
data = request_json["data"]
return (f"The data provided is {data}", 200)
if __name__ == "__main__":
app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))The above is deployed as a cloud run service with Ingress control as Internal.
gcloud run deploy cloud-run-app \
--image gcr.io/<redacted>/cloud_run_app \
--ingress internal \
--platform managed \
--port 8080 \
--service-account cloud-run-svc@<redacted>.iam.gserviceaccount.com \
--no-allow-unauthenticated \
--region northamerica-northeast1What is Ingress Only Setting on cloud run and why it is important ?
Cloud Run as we know is a serverless product and once a service is deployed, it generates run.app url which can be reached via internet by default.
Cloud run provides capability to restrict the traffic to cloud run url using internal only setting as below.
This setting is the most restrictive setting that blocks access from all outside sources.
We will test the connectivity to cloud run from 3 different sources.
- External Source
First, lets try from cloud shell which is external to cloud run.
The result was as expected, all the internet based sources are blocked from accessing cloud run.
2. Resource on service project’s network
Lets test the connectivity from cloud VM instance in the service project’s network.
For this, we have setup a cloud VM instance in the service project’s network as below
When we do a simple curl from the VM instance on service project network, we are able to get the response from cloud run.
This clearly shows the VM instance in service project’s network is able to access the cloud run.
3. Resource on shared VPC
Lets test the connectivity from cloud VM instance in the shared VPC of host project.
We can see the access from the shared VPC — compute VM is not allowed to the cloud run service.
Below is the summary of above tests performed
The most common networking pattern is to have a shared VPC in the host project and share the subnets with the service project.
However the resources on the shared subnet are not able to communicate with cloud run
Now lets take a look at what options are available to allow communication between shared VPC resource and cloud run with ingress — internal only setting.
Option 1: Setup a Organizational VPC perimeter
Add both the service project and host project as part of same VPC perimeter
The VPC perimeter includes both the host and service project and cloud run is added as restricted API.
Ingress policy is configured for allowing the communication from the host project to the service project.
Now, when we test the connectivity, we are able to reach the cloud run api
The solution works however, organizations can only have one access policy at the organizational level. This poses some restrictions with respect to flexibility in policies.
This requires careful deliberation and planning of the ingress/egress policies.
Lets explore another option which works in a similar way — Scoped Access Policy
Option 2 — Setup a Scoped Access Policy
Here we start by creating a access policy with the service project added to the scope
Next we setup a perimeter and ingress policy similar to the above option with the project’s scoped policy.
Now, when the connectivity is tested, we are able to connect to cloud run.
The scoped access policy does provide flexibility as compared to Org level perimeter but requires careful setup of ingress and egress policies.
As seen above, both the options are more of strategic measures which requires good understanding of organizational setup.
Lets explore the third option — setup a internal load balancer
Option 3 — Internal Load Balancer
Let’s start with Internal load balancer setup in the service project as below
We can see the internal load balancer is exposed at the internal IP address (front end) as above.
Lets try to hit the load balancer IP address and check the response
As we can see, the compute VM instance on the shared VPC is able to communicate with the cloud run via the Internal load balancer.
Now lets setup a simple private DNS Zone configuration on the shared VPC for avoiding the usage of IP address as below. Typically here any host names can be provided as resolution will be internal.
For the purposes of demo, cloudrunapp.com is setup with a A record pointing to the internal load balancer IP.
Now we can hit the url as below instead of the IP address.
Depending on the requirements, one of the above 3 options can be chosen to setup the communication from resources in shared VPC to the cloud run in service project
Please connect with me on https://www.linkedin.com/in/murli-krishnan-a1319842/ for any queries.
Happy Learning !!
