GCP SQL instances should require TLS to protect data in transit.

Why is this an issue?

By default, GCP SQL instances accept both encrypted and unencrypted connections. On unsecured networks, such as public networks, unencrypted traffic can be intercepted by an attacker who can then read confidential data. This rule detects google_sql_database_instance resources that do not enforce require_ssl = true in their ip_configuration block.

What is the potential impact?

Unencrypted connections between clients and the SQL instance expose sensitive data to interception. An attacker on the same network can capture database traffic and read or modify confidential information in transit.

How to fix it

Code examples

Noncompliant code example

resource "google_sql_database_instance" "example" { # Noncompliant: TLS is not required
  name             = "example-master-instance"
  database_version = "POSTGRES_11"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
  }
}

Compliant solution

resource "google_sql_database_instance" "example" {
  name             = "example-master-instance"
  database_version = "POSTGRES_11"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
    ip_configuration {
      require_ssl = true
      ipv4_enabled = true
    }
  }
}

Pitfalls

Some connection methods automatically encrypt traffic without requiring require_ssl = true: the Cloud SQL Auth proxy, the Java Socket Library, and built-in mechanisms in App Engine environments. Even when using these methods, enforcing require_ssl = true adds an extra layer of defense in depth by rejecting any unencrypted connection attempts that bypass these mechanisms.

Resources

Documentation

Standards