1

Facing an issue while connecting to my SQL instance from cloud run when a custom domain is mapped. Before the custom domain mapping, the connection was fine, after that it is just throwing Error: connect ETIMEDOUT.

I am using Public IP and seems to me that I should add the IP of the mapped subdomain as allowed networks, the problem is that the mapping is just a CNAME that points to ghs.googlehosted.com. DN where the assigned IPs are dynamic. I can't get from Google their IP range so I can't add a range either.

Based on the docs, Cloud Run uses Cloud SQL Proxy when using sockets, so in theory it should deal with dynamic IPs.

Any help?

Julià Pujol
  • 13
  • 2
  • How do you connect your code to your database? Do you use Cloud SQL instance? (it's not clear). What IP did you allowlisted? – guillaume blaquiere Feb 22 '21 at 19:15
  • I am using sockets on prod and for locally tcp and yes, I am using a Cloud SQL instance. Well I've tried several (that I got from DNS lookups) but when you mapping cloud run to a subdomain from Google Dom., you got a CNAME pointing to ghs.googlehosted.com, which seems that can get, randomly, various ranges. In slack someone point me to this https://www.gstatic.com/ipranges/goog.json, seems that Google keeps it up to date but I feel it's too headache to add all of them, moreover when the documentation seems to indicate that using sockets autom. uses SQL proxy which should deal with dyn IP. – Julià Pujol Feb 23 '21 at 16:05
  • @guillaumeblaquiere also just to make a point, before the mapping it was working well without the need of any IP whitelisting. Now, I'm being forced to use the ugly 0.0.0.0/0 which I want to replace with the right solution as soon as possible. – Julià Pujol Feb 23 '21 at 16:07

1 Answers1

1

You can connect your Cloud SQL database from different ways. Firstly, in the documentation you can see 2 of them:

  • Use public IP of the Cloud SQL database to create a Unix socket to connect your DB. I can understand that Unix socket is sometime not standard for some libraries/frameworks and you prefer IP
  • Use the public IP: if you want to use IP, it's my preferred solution. You have to create a serverless VPC connector to route the internal traffic to the VPC and then reach securely your Database. However, if the Cloud SQL instance isn't in your project, you need to perform peering and it doesn't work (long story, but trust me, VPC peering + Cloud SQL private IP doesn't work).

So, the last solution is to authorized network on Cloud SQL instance, and of course, not 0.0.0.0/0!

To achieve this, you need to get a public IP from Cloud Run when you initiate outgoing connection. You can achieve this with Cloud NAT.

On your Cloud NAT configuration, select your reserved private IP(s) to be sure to reuse always the same. In this configuration, you will also use Cloud NAT, but this time set the egress param to ALL (and not to internal ip range as you can do for private IP access).

Now you have it: a public static IP when Cloud Run initiate outgoing connection. Authorize this IP on Cloud SQL, and enjoy!

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • It worked nicely, many thanks for the explanation! :) Although... I am still wondering why it does not work by default as it did when there was no mapping. I understand that Cloud Run works with a pool of Ips but, while using sockets connection it automatically uses Cloud Proxy, which should allow same-project connections between run and the SQL instance, no matter the IP - as it did before the mapping. Should I understand that the mapping forces Cloud Run egress traffic to have an IP not contemplated by SQL Proxy? I am sure I am missing some point here :S – Julià Pujol Feb 24 '21 at 18:01
  • I'm not sure to understand the design that you have in mind. Anyway, you can consider 3 world: Cloud Run serverless world, Cloud SQL managed world, and you project world. Now, the target is to let all these world communicate safely and securely. You can skip your project and use the Internet (public IP) to make the link, or you use the project to have an internal and secure link. Through the VPC it's easy to secure: plug each world to your VPC and use private IP. Easy. Now for the wild internet.... it's harder! – guillaume blaquiere Feb 24 '21 at 19:24
  • If you use Cloud SQL proxy, a secure tunnel is created, easier directly from Cloud Run, or from your workstation for example. If you want to use a static IP, YOUR static IP, you need to use something that belong to YOUR world: your project, your VPC and your Cloud NAT. Keep in mind that you never reach directly Cloud Run. You reach Google Front End (GFE) which loadbalance the traffic to the active instances of your service. And when you initiate a connection from Cloud Run, you don't pass through GFE, but another IPs pool. – guillaume blaquiere Feb 24 '21 at 19:27
  • With your workstation, you use the same IP for the inbound and the outbound. But in real IT world it's never (or very rarely) the case! – guillaume blaquiere Feb 24 '21 at 19:27