Overview
It is recommended that root access to a MySql Database Instance should be allowed only through specific white-listed trusted IPs.
Rationale
When root access is allowed for any host, any host from authorized networks can attempt to authenticate to a MySql Database Instance using administrative privileges. To minimize attack surface root access can explicitly allowed from only trusted IPs (Hosts) to support database related administrative tasks.
Remediation guidance
Using Command-line
Note: We haven't come across any setting provided by Google cloud console or gcloud utility to update host for a root user. Below remediation uses MySQL client binary to set the host for root user. Similarly, for PostgreSQL instance:
- Login to MySql database instance from
authorized network
mysql connect -u root [INSTANCE_ADRESS]
2. Set host for root user
```sql
UPDATE MySql.user SET Host=\[Host_name/IP\] WHERE User='root';
**Impact**
Only configured hosts will be able access MySQL database Instance with root privileges.
**Default Value**
By default, `root` access to MySql Database Instance is allowed for any Host.
**References**
1. https://cloud.google.com/MySql/docs/MySql/create-manage-users
**Notes**
This recommendation is only applicable to MySQL database Instances. As of now for PostgreSQL, google cloud console/gcloud utility does not offer any relevant setting/option.
Apart from default `root` if there are any other database users with administrative privileges, those should be considered for this recommendation as well.
## 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.
~~~bash
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.
~~~bash
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.
MySql database instances do not allow root login from any Host
Connectors
Covered asset types
Expected check: eq []
sqlUsers(where:{name:"root"OR:[{host:"%"},{host:"0.0.0.0"},{host:""}]}){...AssetFragment}
Google Cloud