Solved

How can I access the Cloud SQL with private IP only from another Project/VPC?


Userlevel 1
Badge

We are trying to migrate a GCE DB instance residing in Project-A / VPC-A, to an existing Cloud SQL instance residing in Project-B / VPC-B that has private IP only. 

icon

Best answer by guillaume blaquiere 10 June 2021, 15:49

You can’t!

 

In fact, when you have a private IP on a Cloud SQL instance, Google creates a peering between the VPC A and the Cloud SQL managed by google world

In project B, to access to VPC A, you need to create another peering. And there is a golden roule in VPC peering with GCP: the peering is not transitive. Which mean:

if A → B and B → C, a CAN’T reach C because of lack of transitivity

https://cloud.google.com/vpc/docs/vpc-peering#restrictions

 

Use public IP without authorized network and Cloud SQL proxy for that. I know, the security teams hate that, and I’m fighting everyday to teach them!!

 

You can also use a dirty hack. Instead of peering between VPC A and VPC B, you can create a VPN. It’s more expensive, but it solves your issue ;)

View original

7 replies

Userlevel 1

Probably the easiest way is to give your Cloud SQL instance a public IP address but don’t have any “allowed networks”. That means that your Cloud SQL instance is still not directly reachable from the public internet even though it has the public IP assigned.

However, with a public IP assigned, it *will* then be accessible using the Cloud SQL proxy by anyone with the appropriate IAM permissions. You can use the Cloud SQL Proxy from “Project B / VPC-B” or from anywhere really. Obviously it’s up to you if that’s an acceptable security trade-off from your environment.

What will *not* work unfortunately is using VPC Peering to peer VPC-A and VPC-B. The reason is that Cloud SQL instances with a Private IP are actually created in a Google Managed VPC and VPC peering is silently created in the background (if you use the console). So there is already VPC peering between VPC-B ↔ Google Managed VPC.

VPC peering is not “transitive” (eg. you cannot route across “middle” VPCs) so route from VPC-A to Google Managed VPC does not work in a peering setup which looks like…

VPC A ↔ VPC B ↔ Google Managed VPC (contains Cloud SQL instance).

I *think* that you could reach the Cloud SQL instance from VPC-A if you connected VPC-A to VPC-B using a VPN instead of peering but I’ve never actually tested that.

Hope that helps and good luck!

Phil.

MakeCloud - A Google Cloud Consultancy & Managed Service Provider.

 

Userlevel 4
Badge +2

You can’t!

 

In fact, when you have a private IP on a Cloud SQL instance, Google creates a peering between the VPC A and the Cloud SQL managed by google world

In project B, to access to VPC A, you need to create another peering. And there is a golden roule in VPC peering with GCP: the peering is not transitive. Which mean:

if A → B and B → C, a CAN’T reach C because of lack of transitivity

https://cloud.google.com/vpc/docs/vpc-peering#restrictions

 

Use public IP without authorized network and Cloud SQL proxy for that. I know, the security teams hate that, and I’m fighting everyday to teach them!!

 

You can also use a dirty hack. Instead of peering between VPC A and VPC B, you can create a VPN. It’s more expensive, but it solves your issue ;)

Userlevel 1
Badge

Thanks for the inputs. It gave me alternative option to choose from. I am thinking also to export/import the GCE DB instance residing in Project A / VPC A via image exportation to Cloud Storage, then import the image to Project B and create a VM from that imported image to VPC B. That way the GCE DB instance can now communicate with the Cloud SQL via private IP. This process generate additional steps. What are your thoughts? Is this efficient?

Userlevel 4
Badge +2

Yes you can do that, but if you want to keep isolation between the project, you can also use a shared VPC.

Userlevel 1

Thanks for the inputs. It gave me alternative option to choose from. I am thinking also to export/import the GCE DB instance residing in Project A / VPC A via image exportation to Cloud Storage, then import the image to Project B and create a VM from that imported image to VPC B. That way the GCE DB instance can now communicate with the Cloud SQL via private IP. This process generate additional steps. What are your thoughts? Is this efficient?

Yes, if you can move the GCE instance that needs to connect to the Cloud SQL instance then of course that works. It really depends on why you have different projects to begin with and the implications of moving it.

Often, different projects are managed by different teams so the IAM policies are different. If the GCE instance doesn’t need to be in Project A, then moving it to Project B is an easy solution. :-)

I’d go with the same solution as for privately connecting from an on-prem VPN to Cloud SQL, described in the next link, which is to create a peering (instead of a VPN) in this case, and publish custom routes to the Private Service Access Google-managed VPC peering and allow access form the other VPC: https://cloud.google.com/sql/docs/mysql/configure-private-ip#vpn

Userlevel 1

I’d go with the same solution as for privately connecting from an on-prem VPN to Cloud SQL, described in the next link, which is to create a peering (instead of a VPN) in this case, and publish custom routes to the Private Service Access Google-managed VPC peering and allow access form the other VPC: https://cloud.google.com/sql/docs/mysql/configure-private-ip#vpn

Sadly, VPC Peering routing is not transitive so this will not work. As the docs say, you need to...

  1. Ensure your VPC network is connected to the external network using a Cloud VPN tunnel or a VLAN attachment for Dedicated Interconnect or Partner Interconnect.

The docs could be more helpful here by explicitly making it clear that VPC peering is not an option rather than just omitting it from the list of ways you can connect from an external network. But unfortunately it does not work.

Reply