Google Cloud SQL User
This page shows how to write Terraform for Cloud SQL User and write them securely.
The User in Cloud SQL can be configured in Terraform with the resource name
google_sql_user. The following sections describe how to use the resource and its parameters.
Example Usage from GitHub
An example could not be found in GitHub.
deletion_policyoptional - string
The deletion policy for the user. Setting ABANDON allows the resource to be abandoned rather than deleted. This is useful for Postgres, where users cannot be deleted from the API if they have been granted SQL roles. Possible values are: "ABANDON".
hostoptional - string
The host the user can connect from. This is only supported for MySQL instances. Don't set this field for PostgreSQL instances. Can be an IP address. Changing this forces a new resource to be created.
The name of the Cloud SQL instance. Changing this forces a new resource to be created.
namerequired - string
The name of the user. Changing this forces a new resource to be created.
passwordoptional - string
The password for the user. Can be updated. For Postgres instances this is a Required field, unless type is set to either CLOUD_IAM_USER or CLOUD_IAM_SERVICE_ACCOUNT.
projectoptional computed - string
The ID of the project in which the resource belongs. If it is not provided, the provider project is used.
typeoptional - string
The user type. It determines the method to authenticate the user during login. The default is the database's built-in user type. Flags include "BUILT_IN", "CLOUD_IAM_USER", or "CLOUD_IAM_SERVICE_ACCOUNT".
Explanation in Terraform Registry
Note: All arguments including the username and password will be stored in the raw state as plain-text. Read more about sensitive data in state. Passwords will not be retrieved when running "terraform import".
Tips: Best Practices for The Other Google Cloud SQL Resources
In addition to the google_sql_database_instance, Google Cloud SQL has the other resources that should be configured for security reasons. Please check some examples of those resources and precautions.
Ensure to disable local_infile setting in MySQL
It is better to disable the local_infile setting in MySQL. If this is not disabled, arbitrary files might be readable.