Google CloudOverview
The log_min_error_statement flag defines the minimum message severity level that are considered as an error statement. Messages for error statements are logged with the SQL statement. Valid values include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels mentioned above. Ensure a value of ERROR or stricter is set.
Rationale
Auditing helps in troubleshooting operational problems and also permits forensic analysis. If log_min_error_statement is not set to the correct value, messages may not be classified as error messages appropriately. Considering general log messages as error messages would make is difficult to find actual errors and considering only stricter severity levels as error messages may skip actual errors. The log_min_error_statement flag should be set to ERROR or stricter. 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
- Go to the
Cloud SQL Instancespage in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances - Select the PostgreSQL instance where the database flag needs to be enabled
- Click
EDIT - Scroll down to the
Flagssection - To set a flag that has not been set on the instance before, click
ADD A DATABASE FLAG, choose the flaglog_min_error_statementfrom the drop-down menu, and set its value to an appropriate one - Click
SAVE - Confirm the changes under
Flagson theOverviewpage
Using Google Cloud CLI
Configure the log_min_error_statement database flag for every Cloud SQL PostgreSQL database instance using the below command:
gcloud sql instances patch <instanceName> --database-flags log_min_error_statement=
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_min_error_statement is ERROR.
References
- https://cloud.google.com/sql/docs/postgres/flags
- 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.
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Ensure 'log_min_error_statement' database flag for Cloud SQL PostgreSQL instance is set to 'Error' or stricter
Connectors
Covered asset types
Expected check: eq []
{
cloudSqlInstances(
where: {
engine: "postgresql"
cloudProvider: "gcp"
dbFlags_SOME: { name: "log_min_error_statement", NOT: {value_IN: ["error", "log", "fatal", "panic"]} }
}
) {
...AssetFragment
}
}
