How do you prevent Google Cloud SQL instances being open to the world?

How exposure happens in Cloud SQL

Google Cloud SQL is usually exposed when an instance is given a public address and the allowed client list is left too broad, stale, or absent. The practical issue is not whether the service is “cloud” but whether any internet host can reach the database port. Review the instance’s network settings, authorised networks, and any connection path created by tooling or automation.

Public exposure also appears after change, not just at initial deployment. A new subnet, a temporary office IP, a CI runner, or a copied configuration can widen access without anyone revisiting the original trust boundary. The safest assumption is that every infrastructure change can reintroduce exposure unless the control is rechecked at the instance and project level.

For a broader control baseline around database hardening, access paths, and related misconfiguration patterns, use Database Security Guide as the parent reference. For Google Cloud-specific hardening context, Google Cloud Security Guide helps place Cloud SQL network exposure inside the wider GCP control model.

What to change to remove world-readable access

Remove public access paths you do not need, then restrict the instance to trusted client networks or private connectivity only. If the workload can use private networking, that is usually the cleaner long-term answer because it reduces dependence on IP allowlists that drift over time. If public reachability must remain, keep the authorised networks list small and explicit, and treat every entry as an exception that needs an owner.

Use the private connectivity pattern that fits the deployment model, then verify that application traffic uses that path consistently. A common failure mode is partial migration, where some clients use private access while others still depend on a leftover public route. That creates the illusion of hardening while the public surface remains live.

For Google Cloud-specific identity and network governance that often sits adjacent to Cloud SQL decisions, Google Cloud IAM and Service Accounts Guide is useful when the database path is being protected through workload permissions as well as network policy. For database access patterns that depend on credential design and connection control, Database Credential and Access Security Guide covers the access side of the same problem.

How to verify the instance stays closed over time

Check the effective network exposure after every change, not only after a security review. Look for drift in authorised networks, project-level policy exceptions, copied instance templates, and any automation that can recreate a permissive configuration. The question to answer is simple: could an arbitrary internet address reach this instance right now?

Use logging and inventory to confirm that the instance configuration matches the intended exposure model. If the database is part of a larger cloud estate, make the exposure check repeatable across environments so staging shortcuts do not become production defaults. Where the platform changes external IP ranges or the client estate changes its egress ranges, update the allowlist or move to private connectivity rather than relying on memory.

Risk and Threat Considerations

Publicly reachable databases are attractive because they turn a network mistake into a direct authentication and brute-force problem. Even when credentials are still required, the open surface increases scanning, credential stuffing, misconfiguration exposure, and the chance that an overlooked account or weak secret becomes the entry point.

Failure mechanism: A public Cloud SQL endpoint plus overly broad authorised networks creates an unnecessary internet attack surface, and that surface can persist after a deployment change or IP drift.

Impact: The result can be unauthorised access attempts, data exposure, service disruption, or a delayed discovery problem where the instance appears protected but is still reachable from outside the intended trust boundary.

Practitioner Guidance

What to verify: Confirm the instance has the narrowest possible exposure model, then test from outside your trusted networks to prove the public path is really closed. A configuration that is “supposed” to be private is not good enough when the database is internet-reachable by mistake.

Decision rule: If the application can use private connectivity, prefer that over maintaining a public endpoint with IP allowlists. If you must keep public access, treat each authorised network entry as a temporary exception with an owner and an expiry review.

Common mistake: Teams harden the first deployment and then stop checking after network, DNS, or instance recreation events. In practice, the exposure control fails most often through drift, not through the initial setup.

Practitioner takeaway: The control objective is not “hide the database once”, it is to make unintended internet reachability impossible to reintroduce without being noticed.

Related resources from NHI Mgmt Group

• How do you secure Vertex AI Workbench instances in Google Cloud?
• How do you configure PostgreSQL logging flags in Google Cloud SQL for security monitoring?
• How do you prevent Google Cloud Functions from being publicly invocable?
• How do you prevent Google Cloud Run services from being publicly accessible?