I'm trying to connect to a postgres database on Google Cloud SQL from Safe FME, a GUI-based desktop application that can connect to postgres databases. It supports SSL but Google Cloud SQL apparently requires the use of "TLS Client Authentication" to connect: providing a specific client key and certificate that you download from the Google Cloud Platform dashboard.
Other hosted postgres providers let you connect simply by ticking the "Use SSL" checkbox. Is there a way to do this with Google Cloud SQL? I want a secure connection but it seems like a lot of software doesn't support the "TLS Client Authentication" way of connecting.
SSL protocols have been considered deprecated as of 2015 (source), so for the best security you should stick to TLS. (MySQL doesn't use SSL anymore for the reason - this is not specific to Cloud SQL). You can create a SSL/TLS cerificate for your Cloud SQL instance by following the instructions here.
If you have and outdated application that doesn't support a version of TLS that is compatible with Postgres, you can always use the Cloud SQL proxy to encrypt connections.
Related
For GCP managed SQL databases: we want to enable SSL/TLS using a common client cert across all our GCP databases. From reviewing the official google docs (https://cloud.google.com/sql/docs/mysql/configure-ssl-instance), it seems the server certificate is not customizable and we require a different client certificate for each database instance.
Is there any solution where we can use a common client cert for multiple database instances?
How do we create client certificate to get validated by aws document db?In aws docs https://docs.aws.amazon.com/documentdb/latest/developerguide/connect_programmatically.html#connect_programmatically-tls_enabled, it is mentioned only about one way ssl i.e.,clients authenticating server certificate.I didn't find information regarding two way ssl supported by aws document db.Can anyone help on this?
Amazon DocumentDB does not support using client certificates to connect to your cluster. Are you looking for client-side certificates to be used by the server for authentication? Amazon DocumentDB only supports SCRAM based authentication.
I have a Google Cloud SQL PostgreSQL database in which I can connect by using SSL and by entering my IP address in allowed connection settings. However, I do not want to list all the IP addresses that is going to connect to this database (because I do not know all the IP addresses). I have around 15 people which I want them to login to my database using QGIS and they should be able to change the data as this is a research. Security is not a big issue as this database will be online for a very short period of time. What connection method can you suggest? The users are not very proficient so I need to setup everything.
I hope you're doing fine.
I would like to suggest to set the connections with the Cloud SQL proxy as it will provide the security needed without using ssl or the need of authorize any network. so basically the set up is to:
Enable the API
Install the proxy client on your local machine
Determine how you will authenticate the proxy
If required by your authentication method, create a service account
Also you can find the steps on "Connecting to Cloud SQL from external applications"
Hope this works for you as I have never used it with QGIS but I believe that as you are using a proxy it won't be hard from there to use it with QGIS as if you connected to a local server.
The option to authorize all apps belonging to the same project is missing in Google Cloud SQL - PostgreSQL. The documentation provide examples for authorization using the network setting 0.0.0.0/0 which simply allows all IPv4 connections.
As we do not know when the App Engine authorization feature would be available for PostgreSQL, what is the next best setting to allow the IP range of App engine instances? I am lost as they are dynamically allocated and ephemeral.
Specs
App Engine Flex (1 aspnetcore + 1 custom service on dotnet core)
Cloud SQL - PostgreSQL
Both belong to the same GCP project
The way to go in this case is to follow the documentation steps:
add 0.0.0.0/0 as the network and configure SSL access from the App Engine Flexible to the Cloud SQL PostgreSQL instance. The crucial part here is to adjust the PostgreSQL instance details, namely the SSL connections configuration. You need to allow only SSL connections to reach your instance, this way the GAE Flex instances (and only them, as having the SSL certificate) will be able to reach the instance with the database, even having dynamically allocated IPs.
To allow SSL connections only in your PostgreSQL instance:
Go to Cloud Console, choose the SQL section
Click on your PostgreSQL instance to view its details
Click the Allow only SSL connections button in the SSL tab
I'm running a Sails.js application that uses a Google Cloud Postgresql instance on Google App Engine. I'm getting a connection refused error when I deploy the application. This is my sailsjs connection config:
postgresGoogle: {
adapter: 'sails-postgresql',
socketPath: '/cloudsql/' + process.env.INSTANCE_CONNECTION_NAME,
user: 'xxxxx',
password: 'xxxxx',
database: 'postgres'
}
If I add the host, it throws a timeout error. Does anyone know the proper way to configure a sailsjs connection with GCP postresql?
Where exactly is your Sails.js application? Is it on App Engine Flex? I would recommend deploying to App Engine Flex, as described here and then connect to the PostgreSQL from the Flex environment. Otherwise, are you using any of the option steps described in this link for connection?
Solved
As of 16 December 2022...
I finally got Sails.js to work today with GCP SQL. If you follow the tutorials from Google you have either Unix Sockets or TCP options to try -- and sadly neither work with out of the box sails-postgres.
My workaround was to connect via a VPC connector with a dedicated IP address. This way I can connect to Cloud SQL using a regular Postgres connection string, directly to the DB.
https://cloud.google.com/appengine/docs/legacy/standard/python/outbound-ip-addresses
Then I whitelisted the new dedicated IP in Cloud SQL security settings, and forced SSL to require valid SSL certificates.
It may not be best practice for now per Google's docs, but it works.