1

I'm looking for a solution (maybe this isn't the best way) to get an app running on one of our GKE clusters in Project-A, to access a Cloud SQL instance in Project-B, over it's an internal IP and ideally via cloud SQL proxy. Some more info:

  • We have VPC peering in between project-A and Project-B, traffic from both VPC's definitely flows fine
  • We have Cloud SQL proxy running in GKE cluster in project-A with the SQL instance in Project-B defined
  • The cloud SQL instance only has an internal Private IP
  • Pods from GKE cluster in Project-B can access Cloud SQL in the same project (Project-B) so I know the internal connectivity is definitely there
  • Only when we briefly add a public IP to the cloud SQL instance in project B, does the connection work from project A via Cloud SQL Proxy

When I try from Project-A to project-B, we get connection time outs.

I understand that when creating a cloud sql instance with an internal IP, that there is another separate VPC peering connection created called servicenetworking-googleapis.com from the VPC in that same project.

My thoughts here, being from a networking background, is that there is no IP route in project-A, to tell pod traffic to go over the VPC peering connection between the 2 projects if it wants to get to the private IP of the cloud SQL instance.

But I wondered if anyone else has tried to same thing.

sc-leeds
  • 399
  • 3
  • 15

2 Answers2

2

I've found in documentation, that transitive peering is not supported. Haven't tried it myself, but it seems that recommended way is to use shared VPC for accessing CloudSQL from multiple projects. In this section: https://cloud.google.com/sql/docs/mysql/private-ip#quick-reference

Transitive peering
Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering. Clients in one project can connect to Cloud SQL instances in multiple projects using Shared VPC networks.

You can use the following guide to set up a Shared VPC between your projects. In summary, it involves the following steps:

  • Set the project that hosts your Cloud SQL instance as a host project, since it is the one sharing the resources which in this case includes your Cloud SQL instance.
  • Select the subnets you would like to share to other projects
  • Set the project where your GKE cluster is hosted as the service project. This service project can then be attached to the host project set up previously.
  • Attach the service project to the host project and set up the appropriate VPC administrator roles so that users from the service project are allowed access to the shared resources.
ErnestoC
  • 2,660
  • 1
  • 6
  • 19
Oleksandr Bushkovskyi
  • 735
  • 1
  • 6
  • 16
  • You're right. Transitive peering is not allowed (tested in the past) and yes, a shared VPC is the best solution for this use case – Puteri Sep 20 '21 at 23:08
  • Using Cloud SQL proxy on the public IP of Cloud SQL (with no authorized network) is also a good solution. A workaround to the VPC peering transitivity issue, is to create a VPN instead a VPC peering between the VPC. of the Project A and B – guillaume blaquiere Sep 21 '21 at 05:41
0

As mentioned in another answer, VPC peering is not transitive. So even though there's a VPC peering between Project A and Project B, that does not mean Project A can communicate with the private IP Cloud SQL instance (which is deployed inside another VPC peered within Project B).

As a workaround, you can deploy a SOCKS5 proxy in Project B and have Project A connect to it using the Cloud SQL Proxy.

ALL_PROXY=socks5://localhost:8000 cloud_sql_proxy \
 -instances=$INSTANCE_CONNECTION_NAME=tcp:5432
enocom
  • 1,496
  • 1
  • 15
  • 22