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 encrypted connections through ssl_mode in their ip_configuration block. The older require_ssl attribute is deprecated in favor of ssl_mode, which takes precedence when both are set.

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 {
      ssl_mode = "ENCRYPTED_ONLY"
      ipv4_enabled = true
    }
  }
}

Pitfalls

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

Resources

Documentation

Standards