Firewall rules for Cloud Run Service Direct VPC Egress appear to behave incorrectly

Google Cloud Serverless Applications
1

I’m trying to understand what the correct way to configure a a firewall rule that allows a Cloud Run service to connect to a VM on the same VPC, via internal IPs, using Direct VPC Egress preferably using network tags.

The only configuration that I can find that works is an Ingress rule with a target of the VM IP and a source of the entire subnet.

Initially I had configured an Ingress rule with a target filter on the VM service account and a source filter on the Cloud Run service account. This resulted in very strange behavior where the first container scheduled could always communicate, but subsequently created containers on cloud run would usually not be able to communicate.

Reviewing documentation I see that this setup is listed as not supported:
https://cloud.google.com/run/docs/configuring/vpc-direct-vpc#gcloud_2:~:text=Using%20service%20identity%20as%20the%20source%20service%20account%20in%20ingress%20firewall%20rules%20applied%20to%20the%20destination%20resource.

The strange non-deterministic behavior threw me off.

Further reviewing the docs I see that an Egress rule with tags is supposed to be supported:
https://cloud.google.com/run/docs/configuring/vpc-direct-vpc#terraform:~:text=In%20the%20egress%20firewall%20rule%2C%20refer%20to%20your%20service%20or%20job%20by%20using%20the%20linked%20service%20account%20service%20identity%2C%20the%20subnet%27s%20IP%20range%2C%20or%20the%20associated%20network%20tags.

However when testing this method, I again see strange behavior where some requests from the Cloud Run service are logged as ‘allow’ on the firewall rules, but generally the cloud run service is unable to hit the VM.

Is this a Cloud Run Direct VPC egress bug, or is there some configuration that is required that is not clear from the docs?

1 Like
2

Hi @jacksonwb ,

It appears that you are facing problems with unsupported service account filtering for Cloud Run’s Direct VPC egress, causing the inconsistent behavior you are observing. Service account-based filtering is not available for this configuration, hence only the initial container was able to communicate.

Instead, I suggest using network tags for your firewall rules:

  1. Ingress Rule: On the VM, configure an Ingress rule that targets the VM (or its tag) and allows traffic from Cloud Run’s internal IP range or network tag. Avoid filtering by service accounts here.
  2. Egress Rule: For Cloud Run, use an Egress rule that allows traffic to the VM using internal IPs and the VM’s network tag.

Double-check firewall rule precedence, and use VPC flow logs to see if any rules are unintentionally blocking traffic. Even though GCP documentation confirms tag-based egress firewall rules are available, the issue you noticed suggests there is a configuration problem, not a bug with the Direct VPC Egress feature. Adhering to the suggestions mentioned may result in effective linkage between the Cloud Run service and the VM.

I hope the above information is helpful.

1 Like
3

Thanks for the reply @greb !

So in order for the tag based rules to work, both an Ingress and Egress rule are required to exist?

Documentation is a bit confusing as it suggests only one or the other is needed:

https://cloud.google.com/run/docs/configuring/vpc-direct-vpc#restrict-access

Also just out of curiosity, why would some containers sometimes work with the unsupported service account filter? Seems like odd behavior.