Trying to find the `recommended dns` data for GCP Cloud SQL instance

Question

I'm working through the documentation for connecting to a private Cloud SQL instance. I created the instance with a private IP (no public access), set up cloud sql proxy on my local, and am able to connect to the network successfully. However, I see in the docs that the console does not automatically add the required private dns records to go from the proxy to the db instance.

When I run this with my sql instance, I do not see the mentioned recommended dns record in the result like the documentation claims exists.

gcloud sql instances describe INSTANCE_NAME \
--project=PROJECT_ID

I do get all the other configuration data, but nothing that matches the suggested dns format: INSTANCE_UID.PROJECT_DNS_LABEL.REGION_NAME.sql.goog.

My instance is a second gen, so I don't know if that has something to do with it. I'd like to get this working via the console before I seek to automate it with Terraform, e.g. I plan on automating this later, but that is not my current goal.

Answer 1

I tried to reproduce the issue at my end. At first I also have created the instance from the console by selecting only private IP as network as shown below

image

I am also unable to see cloud DNS names. It seems like this is expected behavior when an instance is created from the console. As you can observe in the above screenshot,cloud SQL launches instances in PSA(Private Service Access) with Private IP as an option. However to have a cloud DNS name, Instance should be launched in PSC(Private Service Connect) mode and as per doc Create a Cloud SQL instance launching cloudSQL in PSC is not available via console.

To cross verify this,I have launched the instance with --enable-private-service-connect option as stated in above doc, Then I am able to see DNS name with pattern INSTANCE\\\_UID.PROJECT\\\_DNS\\\_LABEL.REGION\\\_NAME.sql.goog. in both console and gcloud sql instances describe command output.

This confirms to me that, To have a DNS name instance should be launched in PSC.

Please go through DNS names and records and PSC blog to have a better understanding of DNS and Private Service Connect.

• ps2goat: Thanks for verifying that. I'm not a fan of things being different between the console and the CLI-- AWS seems to be leagues ahead in this regard.

Answer 2

I'm using Cloud Run, and I ultimately found some documentation. I can use the instance name without having to set up a dns record or Private Service Connect.

There were 3 main things I had to do:

1. I set the host to use unix sockets: /cloudsql/INSTANCE_CONNECTION_NAME, which does come back from that describe call. node postgres automatically adds the /.s.PGSQL.5432 bit to the end. node postgres allows this to be set on the same host connection property, so I didn't have to change the code for that.
2. Disable ssl in the node postgres setup. I still have it required on the Cloud Sql instance, but step 3 requires no ssl on the connection setup.
3. In my Cloud Run service, I clicked Edit & Deploy a new Revision. Scroll down toward the bottom and there's a section for Cloud SQL Connections. Click Add Connection and you can choose the instance you want to allow. This step allows the service to connect to the database instance without all the other setups like vpc peering, etc.

SSL can be required on the database instance, but it needs to be disabled in the Cloud Run application's connection config because step 3 above uses the Cloud SQL Proxy. This automatically uses SSL/TLS to connect to the server, so enabling ssl in the app's connection config causes issues here.

Other things that may have affected this, but I haven't yet undone these to see if they were needed.:

• enable the Cloud SQL Admin API.
• use a public IP. You still need to use the Cloud SQL Proxy or other verified networks to access the db.
• enable private service for the network that the database is using. VPC -> select the VPC; click the Private Services Access tab and then `Private Connections to services. Then enable it.

Answer 3

I went through this recently and am wondering if a private IP is worth the hassle when initially getting set up. Google recommends a private IP in the docs, but it seems to involve a number of extra steps and be a sort of expert-mode.

I think Private Service Connect may be the best approach if you use a private IP. I'm not sure, but it seems to manage DNS entries and integrate with SSL certificate generation.

Here are some dead ends I explored but abandoned. I am sharing in case it helps others save some time:

1. There is no default DNS management for your instance that I can determine without using Private Service Connect. It seems like Google could easily provide a default DNS name to get you started. They do this for a public IP but not for private ones.

2. I set up a DNS name manually, using Cloud DNS, but then I learned that the self-signed certificates do not have the option to specify extra SANs on the certificate. I don't know why.

3. Nothing in gcloud seems to give you a tunnel to your SQL instance, much less launch the standard CLI for your database.

4. The SQL Auth Proxy is a standalone tool that is strangely not integrated into the gcloud tool and strangely is downloaded as an opaque binary. I experimented with it a little bit but am a little afraid of managing a naked executable binary like this, especially in my Docker image that is otherwise more firmly locked down. I am sure that the auth proxy works well once you get it set up, but I ended up backing away from it, both locally and for my Cloud Run instance.

5. There is no way to set up a tunnel from Cloud Run using just the UI. I wish it would work that way, because it's a security risk to set up all these manual pieces: certs, DNS names, TLS configurations. Cloud Run and Cloud SQL seem like flagship products, and it seems like you could request that your Cloud Run instance have a tunnel to your Cloud SQL database, after which you'd get a local port in your Cloud Run containers. This would provide a good hand-off between Google Cloud and a customer's own code, each side taking care of the parts that it has information about.

6. Cloud Terminal cannot communicate directly with your private IP. Even though Cloud Run can connect to your VPC, Cloud Terminal cannot. All the docs I can find, though, for connecting from Cloud Terminal to Cloud SQL are things you would already do on your development machine. Common suggestions are to use a public IP or to set up a bastion.