I have a MySQL database in GCP which has a public and a private IP address. It's using a default network and contains a list of authorized networks (to prevent hacking).
On the other hand, I have a simple Google Cloud Run with a Flask script, a Dockerfile and a requirements.txt. In its configuration, it's in the same GCP project as the database and is being run by a service account that has "SQL Client" access. It is also in the same region as my database, has a connection to my Google Cloud SQL instance and is connected to a serverless VPC (which is itself on the "default" network).
In my Flask script, in my connection parameters I define that I use the public address of my database. This works locally in any case. But once the deployment is done, when I launch the application, I get an error at startup saying that it can't connect (IP address permission problem).
Incidentally, if I try to add my VPC's IP address (10.8.0.16/28) to my authorized database networks, I get the following message:
And in the logs, I have :
Admittedly, the log isn't very meaningful, so I don't really know what to do to be honest...Thanks for your help !!
The issue you are facing is related to security best practices when connecting to a cloud SQL Instance with a private ip address. Here why connecting with the public ip is not ideal and how to address it.
Although connecting via a public IP address is effective locally, it exposes your database to the whole internet, increasing the attack surface and leaving it open to efforts by unauthorized users to access it.
Recommended approach serverless VPC and private IP:
The safest approach is to configure your Cloud SQL instance with a private IP and serverless virtual private cloud.
Make sure your Cloud Run service and Cloud SQL Instance are deployed within the same virtual private cloud (VPC) network. This enables them to communicate with each other using a secret IP address.Verify again if any VPC peering is present.
It is important to confirm that the Cloud Run service account has the Cloud SQL client role given at the project level rather than merely the instance level.
Avoid adding your VPC subnet IP range (10.8.0.16/28) directly to the authorized networks list in the Cloud SQL. This approach limits access only to the VPC subnet itself, not necessarily your cloud run service.
Verify that your Flask Script is connecting to your Cloud SQL instance using the private IP address rather than the public one. This private ip should be resolved within your VPC network.
Refer to this official doc on Learn about using private IP for more information.
Alternate approach (if VPC peering is not possible):
As Guillaume recommended, use Cloud SQL proxy if network segmentation prevents VPC from being practical. This proxy uses the public IP address to provide a secure tunnel to your cloud SQL instance while coexisting with your cloud run service.
However using the Cloud SQL proxies adds an additional layer of complexity and might require extra configuration.