Cloud SQL Has Public IP: Why It's Risky and How to Fix It

A database with a public IP is one of the most common ways teams accidentally put their most sensitive data within reach of the open internet. Cloud SQL makes it easy to provision an instance with a public address, and that default convenience has a way of sticking around long after the testing phase is over. The sql_publicip check catches Cloud SQL instances that have a public IP assigned, so you can decide whether that exposure is intentional or just leftover.

---

What this check detects

The check inspects each Cloud SQL instance in your GCP project and looks at its IP configuration. If the instance has a public IPv4 address assigned (the ipConfiguration.ipv4Enabled field is set to true), the check flags it.

A public IP means the instance is reachable over the internet, subject to whatever authorized networks and SSL settings you have configured. By itself a public IP does not mean the database is wide open, but it does mean the database is no longer isolated inside your VPC. The actual exposure depends on the layers you put in front of it, and those layers are easy to get wrong.

---

Why it matters

When a database has a public IP, anyone on the internet can attempt to reach it. The only things stopping them are your authorized networks list, your SSL configuration, and your database credentials. Each of those is a control that can be misconfigured.

Here are the failure modes we see in the real world:

• Authorized networks set to 0.0.0.0/0. This is depressingly common. Someone needs to connect from their laptop, opens up the whole internet to "test something," and never reverts it. Now your database is reachable by every scanner on the planet.
• SSL not enforced. Without requireSsl, clients can connect in plaintext, and credentials plus query data can be intercepted on the wire.
• Brute force and credential stuffing. A public endpoint invites automated password guessing against your root or application users.
• Exposure of known CVEs. If a vulnerability is found in your database engine, a publicly reachable instance is exploitable far faster than one sitting behind a VPC.

The business impact is straightforward. Databases hold your most valuable data: customer records, credentials, payment information, intellectual property. A breach here is not a minor incident, it is the kind that triggers regulatory disclosure, customer churn, and a very bad week for everyone involved. Several high profile data leaks have traced back to a publicly exposed database that nobody remembered was public.

---

How to fix it

The best fix is to remove the public IP entirely and connect over private IP. If you genuinely need public connectivity, harden it instead. Both paths are below.

Option 1: Switch to private IP (recommended)

First, make sure Private Service Access is configured for your VPC. You need an allocated IP range and a peering connection to the Google services network.

# Allocate an IP range for Private Service Access
gcloud compute addresses create google-managed-services-default \
  --global \
  --purpose=VPC_PEERING \
  --prefix-length=16 \
  --network=default

# Create the private connection to Google services
gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services-default \
  --network=default

Then enable private IP on the instance and disable the public IP:

gcloud sql instances patch INSTANCE_NAME \
  --network=projects/PROJECT_ID/global/networks/default \
  --no-assign-ip

The --no-assign-ip flag removes the public IPv4 address, and --network attaches the instance to your VPC for private connectivity.

Option 2: Harden the public IP (if you must keep it)

If a public IP is unavoidable, narrow the authorized networks to specific trusted ranges and require SSL.

# Restrict access to a specific office or NAT egress range, and require SSL
gcloud sql instances patch INSTANCE_NAME \
  --authorized-networks=203.0.113.10/32 \
  --require-ssl

Console steps

1. Open the Cloud SQL instance in the GCP Console.
2. Go to Connections.
3. Under Networking, uncheck Public IP and check Private IP, selecting your VPC network.
4. If keeping public IP, edit Authorized networks to list only trusted CIDR ranges, and enable Allow only SSL connections.
5. Click Save and wait for the instance to update.

---

How to prevent it from happening again

Fixing one instance is not enough. New instances get created all the time, and the default in many provisioning flows assigns a public IP. Bake the guardrails into your platform.

Terraform: provision private by default

resource "google_sql_database_instance" "main" {
  name             = "app-db"
  database_version = "POSTGRES_15"
  region           = "us-central1"

  settings {
    tier = "db-custom-2-7680"

    ip_configuration {
      ipv4_enabled    = false
      private_network = google_compute_network.vpc.id
      require_ssl     = true
    }
  }

  deletion_protection = true
}

Setting ipv4_enabled = false means no public IP is ever assigned. Make this your module default so every team inherits it.

Organization Policy: block public IPs centrally

GCP has a built in org policy constraint that prevents Cloud SQL instances from getting a public IP at all. Apply it at the organization or folder level and you stop the problem at the source.

gcloud resource-manager org-policies enable-enforce \
  sql.restrictPublicIp \
  --organization=ORGANIZATION_ID

Policy as code in CI/CD

Catch the misconfiguration before it ships. Add an OPA or Conftest rule to your Terraform pipeline:

package cloudsql

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_sql_database_instance"
  resource.change.after.settings[_].ip_configuration[_].ipv4_enabled == true
  msg := sprintf("Cloud SQL instance '%s' must not have a public IP", [resource.address])
}

---

Best practices

• Default to private IP. Public connectivity should be a deliberate, reviewed exception, not the path of least resistance.
• Enforce SSL everywhere. Even on private IP, require SSL so traffic inside the VPC is encrypted.
• Use the Cloud SQL Auth Proxy or IAM database authentication. Move away from long lived passwords and toward short lived, IAM controlled credentials.
• Audit authorized networks regularly. Any range broader than a /24 deserves a second look, and 0.0.0.0/0 should never appear.
• Apply the org policy constraint. A preventive control at the org level beats fixing the same problem instance by instance.
• Enable Cloud SQL audit logging. Know who connected, from where, and when, so you can investigate quickly if something looks off.
• Keep deletion protection on. Unrelated to exposure, but a public database that gets compromised should not also be easy to wipe.

Removing public IPs from your databases is one of the highest leverage security improvements you can make in a GCP environment. It shrinks your attack surface dramatically and costs nothing extra. Combine the one time remediation with an org policy and a CI/CD gate, and this class of finding goes away for good.