Back to controls

Ensure 'log_statement' database flag for Cloud SQL PostgreSQL instance is set appropriately

The value of the `log_statement` flag determined the SQL statements that are logged. Valid values are:

Category

Controls

Low

Applies to

Google Cloud

Coverage

1 queries

Asset types

1 covered

Overview

The value of the log_statement flag determined the SQL statements that are logged. Valid values are:

noneddlmodall

The value ddl logs all data definition statements. The value mod logs all ddl statements, plus data-modifying statements.

The statements are logged after a basic parsing is done and statement type is determined, thus this does not logs statements with errors. When using extended query protocol, logging occurs after an Execute message is received and values of the Bind parameters are included.

A value of 'ddl' is recommended unless otherwise directed by your organization's logging policy.

Rationale

Auditing helps in forensic analysis. If log_statement is not set to the correct value, too many statements may be logged leading to issues in finding the relevant information from the logs, or too few statements may be logged with relevant information missing from the logs. Setting log_statement to align with your organization's security and logging policies facilitates later auditing and review of database activities. This recommendation is applicable to PostgreSQL database instances.

Impact

Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase. Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage.

Remediation guidance

From Google Cloud Console

  1. Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances
  2. Select the PostgreSQL instance where the database flag needs to be enabled
  3. Click Edit
  4. Scroll down to the Flags section
  5. To set a flag that has not been set on the instance before, click Add item, choose the flag log_statement from the drop-down menu, and set its value to an appropriate one
  6. Click Save
  7. Confirm the changes under Flags on the Overview page

Using Google Cloud CLI

Configure the log_statement database flag for every Cloud SQL PostgreSQL database instance using the below command:

gcloud sql instances patch <instanceName> --database-flags log_statement=<ddl|mod|all|none>

Note: This command will overwrite all database flags that were previously set. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ("=").

Default Value

By default log_statement is NONE.

References

  1. https://cloud.google.com/sql/docs/postgres/flags
  2. https://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT

Additional information

WARNING: This patch modifies database flag values, which may require the instance to be restarted. Check the list of supported flags https://cloud.google.com/sql/docs/postgres/flags - to see if your instance will be restarted when this patch is submitted.

Note: Some database flag settings can affect instance availability or stability, and remove the instance from the Cloud SQL SLA. For information about these flags, see Operational Guidelines.

Note: Configuring the above flag restarts the Cloud SQL instance.

Service-wide remediation

Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.

Google Cloud

Use organization or folder policies where available, shared project templates, logs and alerting baselines, and IaC modules so new resources inherit the secure setting.

Operational rollout

  1. Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
  2. Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
  3. Re-scan and track approved exceptions with an owner and expiry date.

Query logic

These are the stored checks tied to this control.

Ensure 'log_statement' database flag for Cloud SQL PostgreSQL instance is set appropriately

Connectors

Google Cloud

Covered asset types

CloudSQLInstance

Expected check: eq []

{
  cloudSqlInstances(
    where: {
      engine: "postgresql"
      cloudProvider: "gcp"
      dbFlags_NONE: { name: "log_statement" }
    }
  ) {
     ...AssetFragment
  }
}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon