Skip to content

google_sql_database_instance deletes root@% user even when password is set via Terraform #22562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kthirumalasetty opened this issue Apr 29, 2025 · 5 comments

Comments

@kthirumalasetty
Copy link

kthirumalasetty commented Apr 29, 2025

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
  • If an issue is assigned to a user, that user is claiming responsibility for the issue.
  • Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Terraform Version & Provider Version(s)

Terraform v1.11.4
on darwin_arm64

  • provider registry.terraform.io/hashicorp/google v6.33.0
  • provider registry.terraform.io/hashicorp/null v3.2.4
  • provider registry.terraform.io/hashicorp/random v3.6.3

Affected Resource(s)

google_sql_database_instance

Terraform Configuration

provider "google" {
  project = <PROJECT_ID>
  region  = "us-east4"
}

terraform {
  required_version = ">= 1.3"
  required_providers {
    null = {
      source  = "hashicorp/null"
      version = "~> 3.2.2"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6.0"
    }
    google = {
      source  = "hashicorp/google"
      version = ">= 5.11.0"
    }
  }
}


resource "google_sql_database_instance" "mysql_instance" {
  name             = "testdb"
  database_version = "MYSQL_8_0"
  region           = "us-east4"
  root_password    = random_password.password.result

  settings {
    tier                        = "db-custom-1-3840"  # Customize based on workload
    availability_type           = "ZONAL"             # Or "REGIONAL" for HA
    activation_policy           = "ALWAYS"
    deletion_protection_enabled = false

    ip_configuration {
      ipv4_enabled    = false
      private_network = data.google_compute_network.this.self_link
    }

    database_flags {
      name  = "default_authentication_plugin"
      value = "caching_sha2_password"
    }

    location_preference {
      zone = "us-east4-a"
    }
  }
}

resource "random_password" "password" {

  min_lower   = 1
  min_numeric = 1
  min_upper   = 1
  length      = 32
  special     = false
  min_special = 0

  lifecycle {
    ignore_changes = [
      min_lower, min_upper, min_numeric
    ]
  }
}

data "google_compute_network" "this" {
  name    =  <VPC_NAME>
  project = <SHARED_VPC_PROJECT_ID>
}

Debug Output

During terraform apply, instance creation succeeds, but the root@% user is deleted from the MySQL instance, even though a password was specified via root_password.
No errors are thrown.
After creation, connecting to the instance shows the root@% user is missing.

apply_debug.txt

terraform_tfstate.txt

Screenshot from Cloud SQL UI:
Image

Expected Behavior

When a root_password is provided in the google_sql_database_instance block, the root@% user should be preserved on the SQL instance after creation.

Actual Behavior

Despite providing a root_password, Terraform deletes the root@% user during SQL instance creation.

Steps to reproduce

  1. Create a simple Terraform config that provisions a MySQL 8.0 Cloud SQL instance with a root_password set.
  2. terraform apply
  3. Inspect the users on the created instance:
SELECT user, host FROM mysql.user;
  1. Notice that root@% is missing.
  2. Similarly, go the Google Cloud SQL Console Page, and notice the root user is missing under the USERS tab.
  3. Check the Operations logs, to notice, the root user was deleted right after the Cloud SQL Instance was created.

Important Factoids

  • Google Cloud Support reproduced and confirmed this behavior internally.
  • Google's explanation suggests that this is currently intended behavior within Terraform, not a platform bug in Cloud SQL.
  • Google Support recommends using a separate google_sql_user resource to explicitly recreate the root@% user after instance creation as a workaround:
resource "google_sql_user" "root_user" {
  instance = google_sql_database_instance.default.name
  name     = "root"
  host     = "%"
  password = "StrongPassword123!"
}
  • Even after setting default_authentication_plugin to caching_sha2_password, behavior remained unchanged — root@% still deleted.

References

Related Terraform documentation: google_sql_database_instance

b/416552133

@github-actions github-actions bot added forward/review In review; remove label to forward service/sqladmin-cp labels Apr 29, 2025
@ggtisc ggtisc self-assigned this Apr 29, 2025
@ggtisc
Copy link
Collaborator

ggtisc commented Apr 29, 2025

Hi @kthirumalasetty

Could you be more directly on the instructions since you are providing many shared codes this may cause confusion. Please just specify and confirm the code you are using and confirm if the google_sql_user is being deleted from the tfstate file

@kthirumalasetty
Copy link
Author

Hi @kthirumalasetty

Could you be more directly on the instructions since you are providing many shared codes this may cause confusion. Please just specify and confirm the code you are using and confirm if the google_sql_user is being deleted from the tfstate file

I have updated the description with the actual Terraform Code, debug output for Terraform Apply and terraform state file. Please note, I masked any information that I thought were sensitive, such as Project IDs.

@ggtisc
Copy link
Collaborator

ggtisc commented May 7, 2025

Thanks @kthirumalasetty

I checked the logs, but after deleting the default user it was created the new root_user just a few seconds later, and this looks like a correct behavior since you are creating a new user for your google_sql_database_instance and you don't need the old user which is just created behind the scenes for internal purposes. Do you have the newly created user called root_user on your logs, cloud and tfstate file?

@kthirumalasetty
Copy link
Author

kthirumalasetty commented May 8, 2025

Thanks @kthirumalasetty

I checked the logs, but after deleting the default user it was created the new root_user just a few seconds later, and this looks like a correct behavior since you are creating a new user for your google_sql_database_instance and you don't need the old user which is just created behind the scenes for internal purposes. Do you have the newly created user called root_user on your logs, cloud and tfstate file?

@ggtisc Thank you for your response.

I am a bit confused about the newly created "root_user" you’re referring to. In our Terraform code, we are not creating a new user named root_user, and there is no such user present in our logs, Cloud SQL console, or the Terraform state file.

If you review the Terraform resources I shared earlier, you’ll see that we are setting the password for the default "root" user by specifying the root_password parameter within the google_sql_database_instance resource. According to the documentation (https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/sql_database_instance), only "root" users without a password should be deleted. However, as shown in our logs, Cloud SQL console, and Terraform state file, the root user—with the password properly set—is still being deleted.

To clarify, I am resending the main.tf, apply output, and the Terraform state file for your reference (with parts of the project IDs masked).

apply_2025MAY08.out.txt
main.tf.txt
terraform.tfstate.txt

@ggtisc
Copy link
Collaborator

ggtisc commented May 8, 2025

After checking this issue with @hao-nan-li it seems that there is a possibility that this issue has an internal configuration which is conflicting with the user. For this reason I'm forwarding this issue for a deep review

@ggtisc ggtisc removed their assignment May 8, 2025
@ggtisc ggtisc removed the forward/review In review; remove label to forward label May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants