Cloud SQL instances that still accept unencrypted database connections

What the default SSL mode allows

Cloud SQL offers three SSL enforcement modes. The SSL configuration guide lists ALLOW_UNENCRYPTED_AND_ENCRYPTED as the default, which accepts both plaintext and TLS connections and does not verify client certificates. ENCRYPTED_ONLY accepts only TLS, and TRUSTED_CLIENT_CERTIFICATE_REQUIRED accepts only TLS with a valid client certificate.

So an instance nobody configured will take a plaintext connection from any client that asks for one. On a private network that is still traffic other workloads may be able to observe; on a public IP, Google says it strongly recommends enforcing SSL for all connections. Clients that use the Cloud SQL Auth Proxy or the Cloud SQL Connectors are encrypted regardless of the mode, which is why enforcing TLS rarely breaks well-configured applications.

Checking the SSL setting on each instance

gcloud sql instances list \
  --format="table(name, databaseVersion, settings.ipConfiguration.sslMode, settings.ipConfiguration.requireSsl)"

Google recommends using SSL mode instead of the legacy require-ssl parameter, and warns that the two should not conflict, so check both columns.

The gate ZopNight applies

ZopNight confirms the resource is a genuine Cloud SQL instance by checking it has a recorded machine tier, then reads the legacy requireSsl field of the instance’s IP configuration. The rule fires whenever that value is absent or anything other than true. It does not look at traffic, certificates or which clients connect.

When no finding appears

Resources without a recorded tier are skipped, so partial inventory records do not generate alerts. An instance with requireSsl set to true is silent. The Cloud SQL Admin API reference lists the valid pairs: on MySQL and PostgreSQL, ENCRYPTED_ONLY goes with requireSsl=false and only TRUSTED_CLIENT_CERTIFICATE_REQUIRED goes with true; on SQL Server, ENCRYPTED_ONLY goes with true. So a MySQL or PostgreSQL instance enforcing server-only TLS is still reported, even though it rejects plaintext. If the instance also has a public address, that exposure is reported separately by GCP Cloud SQL Instance Has Public IP Enabled.

Exposure, not a saving

There is no cost change and ZopNight reports a $0 saving. The risk is interception: database credentials, query text and result sets in plaintext wherever the traffic travels, and an easy audit failure under most compliance frameworks.

Enforcing encrypted connections

1. Find clients that connect without TLS. Moving them to the Cloud SQL Auth Proxy or a Cloud SQL Connector is the least effort path, since those encrypt automatically.

2. For direct clients, download the server CA certificate and set the client option, for example ssl-mode=REQUIRED for MySQL clients or sslmode=require for PostgreSQL.

3. Enforce it on the instance:

   gcloud sql instances patch INSTANCE_NAME --ssl-mode=ENCRYPTED_ONLY

   This blocks plaintext. On MySQL and PostgreSQL the finding only clears with TRUSTED_CLIENT_CERTIFICATE_REQUIRED (mutual TLS), since that is the mode Google pairs with requireSsl=true; if you settle on ENCRYPTED_ONLY, record the finding as accepted.

4. Test every application connection. Plaintext clients will fail from this point on.