Quoting https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless#enabling
While Google Cloud Armor can be configured for backend services with Cloud Run (fully managed), Cloud Functions, and App Engine backends, there are certain limitations associated with this capability, especially with Cloud Run (fully managed) and App Engine. Users who have access to the default URLs assigned to these services by Google Cloud can bypass the load balancer and go directly to the service URLs, circumventing any configured Google Cloud Armor security policies.
What would be the best way to avoid the bypass of Cloud Armor by an attacker targetting the Cloud Run URL (*.run.app)?
Normally I would make Cloud Run only invocable by a service account but Cloud Load Balancer can't use service accounts to call Cloud Run. An alternative is to configure Cloud Load Balancer to use a token in a header and configure the app running in Cloud Run to only accept calls with the correct header/token but I would prefer not to have to do that in the app.
You should restrict the ingress of your service to "Internal and Load Balancing" to disable access from the default domain and only allow traffic to come from Cloud Armor:
gcloud beta run services update SERVICE --ingress internal-and-cloud-load-balancing
Related
I'd like to add cache to my Django app hosting on Cloud Run.
From Django official docs, we can connect Django to a memory-based cache. Since I'm using Cloud Run, the memory get cleaned.
Memotystore seems good for this purpose, but there's only tutorial for flask and redis.
How could I achieve this?
Or should I just use a database caching?
Connect Redis instance to Cloud Run service using the steps in
documentation.
To connect from Cloud Run (fully managed) to Memorystore you need to
use the mechanism called "Serverless VPC Access" or a "VPC
Connector"
First, you have to create a Serverless VPC Access Connector
and then configure Cloud Run to use this connector
See connecting to a VPC Network for more information.
Alternatives to using this include:
Use Cloud Run for Anthos, where GKE provides the capability to
connect to Memorystore if the cluster is configured for it.
Stay within fully managed Serverless but use a GA version of the
Serverless VPC Access feature by using App Engine with Memorystore.
See this answer to connect to Memorystore from Cloud Run using an SSH
tunnel via GCE.
I have multiple ESPv2 APIs hosted on Cloud Run. One for each service, each with their own *.run.app URIs.
My question is should I setup multiple Google Cloud Load Balancers, one for each Cloud Run service or map multiple Cloud Run services to the same Cloud Load Balancer.
I have 2 google cloud services:
Google Cloud Run Service (Node Js / Strapi)
Google Cloud SQL Service (Mysql)
I have added the Cloud SQL connection to the Google Cloud Run Service from the UI, and have a public IP for the Google Cloud SQL Service. On top of that I have added the Run Service IP to the Authorised networks of SQL Service.
If I try and connect from another server (external from Google cloud) I can easily connect to the Google Cloud SQL Service and execute queries.
But if I try and connect from inside the GCloud Run Service with exactly the same settings (Ip, database_name, etc) my connection hangs and I get a timeout error in the logs...
How to properly allow Gcloud SQL to accept connections from GCloud RUN?
I looked for other answers in here, but they all look very old (around 2015 )
You can use 3 modes to access to your database
Use the built-in feature. In this case, you don't need to specify the IP address, it's a linux socket that is open to communicate with the database as described in the documentation
Use Cloud SQL private IP. This time, no need to configure a connection in the Cloud Run service, you won't use it because you will use the IP, not the linux socket. This solution required 2 things
Firstly attach your database to your VPC and give it a private IP
Then, you need to route the private IP traffic of Cloud Run through your VPC. For this you have to create, and then to attach to the Cloud RUn service, a serverless VPC Connector
Use CLoud SQL public IP. This time again, no need to configure a connection in the Cloud Run service, you won't use it because you will use the IP, not the linux socket. To achieve this, you need more steps (and it's less secure)
You need to route all the egress traffic of Cloud Run through your VPC. For this you have to create, and then to attach to the Cloud RUn service, a serverless VPC Connector
Deploy your Cloud Run service with the Serverless VPC Connector and the egress connectivity param to "all"
Then create a Cloud NAT to route all the VPC Connector ip range traffic to a single IP (or set of IPs) (The link is the Cloud Functions documentation, but it works exactly in the same way)
Finally authorize the Cloud NAT IP(s) on Cloud SQL authorized networks.
In your case, you have whitelisted the Cloud Run IP, but it's a shared IP (other service can use the same!! Be careful) and it's not always the same, there is a pool of IP addresses used by Google cloud.
I'm trying to create a multi-region Google Cloud Run setup and can't find any documentation.
My goal is creating an Google HTTPS Load Balancer and map the targets as my 3 Google Cloud Run instances.
https://lb.test.com/ >
eu.test.com > Europe Cloud Run
na.test.com > North America Cloud Run
sa.test.com > South America Cloud Run
Problem is, I can't find the option of mapping my HTTPS load balancer into my Cloud Run instances.
If this is not possible yet, can I use an external DNS LB such as AWS Route 53?
Thanks!
Mapping load balancer to cloud run is possible now. This can be achieved by creating NEGs (Network Endpoint Groups) which points to a cloud run service.
I have implemented this today, and came across this thread. To find out how to implement this follow instructions in
https://cloud.google.com/load-balancing/docs/negs/setting-up-serverless-negs#creating_the
I have recently published a guide on this on our official documentation: http://cloud.google.com/run/docs/multiple-regions
The solution involves adding the newly introduced "Serverless Network Endpoint Groups" as backends to your load balancer.
I do not think you can use a Google HTTPS Load Balancer to make cloud run service multiregional (HTTPS Load Balancer supports only compute engine vm as backend). Your question was very interesting and I did some research.
The only useful documents I found about this topic:
Running Multi-Region Apps on Google Cloud (Cloud Next '19).
Going Multi-Regional in Google Cloud Platform
They are explaining how you can make a cloud service multiregional using Apigee (some proxy servers HA Proxy, Nginx).
I configured a Cloud Armor policy however when I try to apply the policy to a new target the '+Add Target' button is disabled.
I understand that you can't apply the policy to a new target.
This should be related to your HTTP(S) Load Balancer, because Cloud Armor is used in conjunction with HTTP(S) Load balancer. See the below link for more details:
https://cloud.google.com/armor/docs/security-policy-concepts
Once you have a healthy load balancer, it should be available to be added to your cloud armor policy. Also, make sure that the Load balancer is not using CDN there are some limitations. Cloud Armor Security Policies and IP blacklist/whitelist are not supported for Cloud CDN in the Beta release. If you try to associate a Cloud Armor Security Policy for a backend service and Cloud CDN is enabled, the config will be rejected. Targets are Google Cloud Platform resources that you want to control access to. For the Beta release, you can only use non-CDN HTTP(S) load balancer backend services as targets.
Also, you can try to apply the policy using the gcloud command line tool, and check if it is working or not. See the link below for more insight on gcloud command line tool.
https://cloud.google.com/kubernetes-engine/docs/how-to/cloud-armor-backendconfig