Sign in to your Google Cloud account. If you're new to
Google Cloud,
create an account to evaluate how our products perform in
real-world scenarios. New customers also get $300 in free credits to
run, test, and deploy workloads.
In the Google Cloud console, on the project selector page,
select or create a Google Cloud project.
Roles required to select or create a project
Select a project: Selecting a project doesn't require a specific
IAM role—you can select any project that you've been
granted a role on.
Create a project: To create a project, you need the Project Creator role
(roles/resourcemanager.projectCreator), which contains the
resourcemanager.projects.create permission. Learn how to grant
roles.
To initialize the gcloud CLI, run the following command:
gcloudinit
In the Google Cloud console, on the project selector page,
select or create a Google Cloud project.
Roles required to select or create a project
Select a project: Selecting a project doesn't require a specific
IAM role—you can select any project that you've been
granted a role on.
Create a project: To create a project, you need the Project Creator role
(roles/resourcemanager.projectCreator), which contains the
resourcemanager.projects.create permission. Learn how to grant
roles.
Assign the necessary cloudsql.instanceUser IAM
role to IAM principals such as IAM users,
service accounts,
or groups to
log in to the Cloud SQL instance.
If you are adding an individual user or individual service account to the
Cloud SQL instance, then you need to assign the IAM
role individually
to each user and service account.
If you are adding a group, then you need
to assign the IAM role to the group as the members of
the group automatically inherit the IAM permissions
associated with the IAM role. For more information about creating groups in Cloud Identity,
see Create and manage Google groups in the Google Cloud console.
Add an IAM policy binding to a user, service account, or group
This procedure adds a policy binding to the IAM policy of a
specific project, given a project ID and the binding. The binding command
consists of a member, a role, and an optional condition.
The database username must be the IAM user's email address, for
example example-user@example.com. It must be all lowercase and use quotes
because it contains special characters (@ and .).
Console
In the Google Cloud console, go to the Service accounts page.
In New members, enter an email address. You can add
individual users, service accounts, or groups as members, but every project
must have at least one principal as a member.
In Role, navigate to Cloud SQL and
select Cloud SQL Instance User.
Optional: If you want to connect using the Cloud SQL Auth Proxy or
Cloud SQL Language Connectors, then also select Cloud SQL Client.
If you want to connect using the Cloud SQL Auth Proxy or Cloud SQL Language Connectors,
then run
gcloud projects add-iam-policy-binding
again with the --role=roles/cloudsql.client flag.
Add a policy binding to a service account
Replace the following:
PROJECT_ID: the ID for the project you want to authorize the
user to use.
SERVICE_ACCT: the email address for the service
account.
If you want to connect using the Cloud SQL Auth Proxy or Cloud SQL Language Connectors,
then run
gcloud projects add-iam-policy-binding
again with the --role=roles/cloudsql.client flag.
Add a policy binding to a Cloud Identity group
Replace the following:
PROJECT_ID: The ID for the project that you want to authorize
members of the group to use.
GROUP_EMAIL_ADDRESS: The email address for the group. For
example, example-group@example.com.
All members of the specified group are granted the Cloud SQL Instance User
role and can log in to instances in this project.
If you want to connect using the Cloud SQL Auth Proxy or Cloud SQL Language Connectors,
then run
gcloud projects add-iam-policy-binding
again with the --role=roles/cloudsql.client flag.
Terraform
To add the required policy-binding to the IAM user and
service accounts, use a Terraform resource.
data "google_project" "project" {
}
resource "google_project_iam_binding" "cloud_sql_user" {
project = data.google_project.project.project_id
role = "roles/cloudsql.instanceUser"
members = [
"user:test-user@example.com",
"serviceAccount:${google_service_account.default.email}"
]
}
resource "google_project_iam_binding" "cloud_sql_client" {
project = data.google_project.project.project_id
role = "roles/cloudsql.client"
members = [
"user:test-user@example.com",
"serviceAccount:${google_service_account.default.email}"
]
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called a root module).
In Cloud Shell, create a directory and a new
file within that directory. The filename must have the
.tf extension—for example main.tf. In this
tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade
option:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and entering yes
at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud project to view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set the
deletion_protection argument to false.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
entering yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and entering yes at the prompt:
terraform destroy
Terraform
To add the required policy-binding to the IAM user and
service accounts, use a Terraform resource.
data "google_project" "project" {
}
resource "google_project_iam_binding" "cloud_sql_user" {
project = data.google_project.project.project_id
role = "roles/cloudsql.instanceUser"
members = [
"group:example-group@example.com"
]
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called a root module).
In Cloud Shell, create a directory and a new
file within that directory. The filename must have the
.tf extension—for example main.tf. In this
tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade
option:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and entering yes
at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud project to view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set the
deletion_protection argument to false.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
entering yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and entering yes at the prompt:
terraform destroy
REST
Grant the cloudsql.instanceUser and cloudsql.client
roles to both types of accounts by editing the JSON or YAML binding policy
returned by the get-iam-policy command. Note that this policy
change does not take effect until you set the updated policy.
Add an individual IAM user or service account to a Cloud SQL instance
You must create a new user account for each individual IAM user
or service account that you are adding to the Cloud SQL instance in order
to access databases. If you are adding an IAM group, then you
don't need to create a user account for each member of that group.
The database username must be the
IAM user's email address and all lowercase.
For example, example-user@example.com.
When using REST commands, the username must use quotes because it contains
special characters (@ and .). Service accounts use the format
service-account-name@project-id.iam.gserviceaccount.com.
To add an individual IAM user or service account, you add a new
user account and select IAM as the authentication method:
Console
In the Google Cloud console, go to the Cloud SQL Instances page.
To open the Overview page of an instance, click the instance name.
Select Users from the SQL navigation menu.
Click Add user account. The Add a user account to
instance instance_name tab opens.
Click the Cloud IAM radio button.
Add the email address for the user or service account you want to add in the
Principal field.
Click Add. The user or service account is now in the user
account list.
If the user doesn't have the cloudsql.instanceUser IAM
role assigned after user account creation, then a
icon
appears next to the username.
To give the user login permissions, click
the icon, and then select Add IAM role. If the icon no longer appears,
then the user account is assigned the IAM role that gives
the login permission.
gcloud
Create a user account
Use the email, such as example-user@example.com, to identify the user.
Replace the following:
USERNAME: the email address for the user.
INSTANCE_NAME: the name of the instance you want to authorize
the user to access.
To add IAM user and service accounts on an instance with
IAM database authentication enabled,
use a Terraform resource.
resource "google_sql_database_instance" "default" {
name = "postgres-db-auth-instance-name-test"
region = "us-west4"
database_version = "POSTGRES_14"
settings {
tier = "db-custom-2-7680"
database_flags {
name = "cloudsql.iam_authentication"
value = "on"
}
}
}
# Specify the email address of the IAM user to add to the instance
# This resource does not create a new IAM user account; this account must
# already exist
resource "google_sql_user" "iam_user" {
name = "test-user@example.com"
instance = google_sql_database_instance.default.name
type = "CLOUD_IAM_USER"
}
# Specify the email address of the IAM service account to add to the instance
# This resource does not create a new IAM service account; this service account
# must already exist
# Create a new IAM service account
resource "google_service_account" "default" {
account_id = "cloud-sql-postgres-sa"
display_name = "Cloud SQL for Postgres Service Account"
}
resource "google_sql_user" "iam_service_account_user" {
# Note: for PostgreSQL only, Google Cloud requires that you omit the
# ".gserviceaccount.com" suffix
# from the service account email due to length limits on database usernames.
name = trimsuffix(google_service_account.default.email, ".gserviceaccount.com")
instance = google_sql_database_instance.default.name
type = "CLOUD_IAM_SERVICE_ACCOUNT"
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called a root module).
In Cloud Shell, create a directory and a new
file within that directory. The filename must have the
.tf extension—for example main.tf. In this
tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade
option:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and entering yes
at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud project to view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set the
deletion_protection argument to false.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
entering yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and entering yes at the prompt:
terraform destroy
REST v1
Create a user account
Before using any of the request data,
make the following replacements:
PROJECT_ID: the project ID
INSTANCE_ID: the instance ID for the instance you are adding the user to
USERNAME: the email address for the user
HTTP method and URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID/users
Request JSON body:
{
"name": "USERNAME",
"type": "CLOUD_IAM_USER"
}
To send your request, expand one of these options:
curl (Linux, macOS, or Cloud Shell)
Save the request body in a file named request.json,
and execute the following command:
A maximum of 200 IAM groups can exist on a Cloud SQL
instance at any time. Inactive groups count towards this limit.
IAM group names have the same length limitations as
PostgreSQL identifiers
and can only be 63 characters long.
If you have an IAM group with a name that exceeds a database
engine's username length limitation, then you can still use it for IAM group authentication
by nesting it under a parent IAM group that has a name that
complies with the length limitation. The parent IAM group must
be added to the instance before the nested group can be used.
Console
In the Google Cloud console, go to the Cloud SQL Instances page.
To open the Overview page of an instance, click the instance name.
Select Users from the SQL navigation menu.
Click Add user account. The Add a user account to
instance instance_name tab opens.
Click the Cloud IAM radio button.
Add the email address for the group you want to add in the
Principal field.
Click Add. The group is now in the user list.
If the group doesn't have the cloudsql.instanceUser
IAM role assigned after user account creation,
then a
icon appears next to the group.
To give the group members login permissions, click
the icon, and then select Add IAM role.
If the icon no longer appears, then all members of the group are assigned the role that gives the login permission.
gcloud
Replace the following:
GROUP_EMAIL_ADDRESS: the email address of the
Cloud Identity group that you want to add to the instance.
For example, example-group@example.com.
INSTANCE_NAME: the name of the instance where you want to
add the group.
To add IAM user and service accounts on an instance with
IAM database authentication enabled,
use a Terraform resource.
resource "google_sql_database_instance" "default" {
name = "postgres-iam-group-auth-instance-name"
region = "us-west4"
database_version = "POSTGRES_16"
settings {
tier = "db-custom-2-7680"
database_flags {
name = "cloudsql.iam_authentication"
value = "on"
}
}
}
# Specify the email address of the Cloud Identity group to add to the instance
# This resource does not create a Cloud Identity group; the group must
# already exist
resource "google_sql_user" "iam_group" {
name = "example-group@example.com"
instance = google_sql_database_instance.default.name
type = "CLOUD_IAM_GROUP"
}
data "google_project" "project" {
}
resource "google_project_iam_binding" "cloud_sql_user" {
project = data.google_project.project.project_id
role = "roles/cloudsql.instanceUser"
members = [
"group:example-group@example.com"
]
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called a root module).
In Cloud Shell, create a directory and a new
file within that directory. The filename must have the
.tf extension—for example main.tf. In this
tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade
option:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and entering yes
at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud project to view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set the
deletion_protection argument to false.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
entering yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and entering yes at the prompt:
terraform destroy
REST v1
Before using any of the request data,
make the following replacements:
PROJECT_ID: the project ID
INSTANCE_ID: the instance ID for the instance you are adding the Cloud Identity
group to
GROUP_EMAIL: the email address for the Cloud Identity group
HTTP method and URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID/users
Add members of a group to a Cloud SQL instance automatically
When you add an IAM group to a Cloud SQL instance,
all members (users and service accounts) of that group inherit the IAM
permissions to authenticate to the instance. You don't need to add the group
member individually to the Cloud SQL instance. After a group member
logs in and authenticates successfully to the primary
instance for the first time, Cloud SQL creates a group user
account or group service account for that group member. You can view the group
member listed on the instance after their first successful login.
Upon failover, as long as the failover instance has the appropriate groups,
IAM group users can continue to log in and be created.
Migrate existing IAM users to use IAM group authentication
Existing IAM users of type CLOUD_IAM_USER or CLOUD_IAM_SERVICE_ACCOUNT
don't use IAM group authentication.
You can migrate these users to use IAM group authentication.
Add these users to a group.
Add the group to your instance.
Assign the group sufficient IAM permissions to
let group members connect to your instances. These changes might take time
to propagate. For more information about propagation times, see
Access change propagation.
Assign database privileges assigned to the IAM users you are
migrating to the group.
After group membership changes and IAM permissions are
applied, delete the existing IAM user from your instance.
The next time that the IAM user logs in successfully, the user is
recreated as an IAM group user which can use IAM group authentication.
Manage group members on a Cloud SQL instance
When you add an IAM group to a Cloud SQL instance, all
members (user or service accounts) of that group inherit the IAM
permission to authenticate to the instance. You can control access to an
instance by managing the group in Cloud Identity. For example, if you
want to give a new user access to an instance, then add the user as a group member
in Cloud Identity. You don't need to remove or add group members separately
at the Cloud SQL instance level because changes to group membership are
propagated from to the Cloud SQL instance automatically. Changes
to group membership, such as the addition or removal of a member, take about
15 minutes to propagate. The 15 minute propagation delay from Cloud SQL
happens in parallel with the time required for IAM changes to propagate.
Granting or revoking database privileges for an IAM group in PostgreSQL takes effect
immediately. For example, if you revoke access to a table,
members of that IAM group lose access to that table instantly.
It's possible for a user or service account to be a member of multiple
IAM groups. If a user or service account belongs to multiple
IAM groups on an instance, then they have all the
IAM permissions and database privileges
combined from each of those IAM groups.
When you add a new member (user or service account) to the IAM
group in Cloud Identity and they log in to the instance successfully
for the first time, then they inherit the database privileges granted to the
group automatically.
Grant database privileges to an individual IAM user or service account
When an individual IAM user or service is added to a
Cloud SQL instance, that new account is granted no privileges on
any databases, by default. They can only run queries against any database object
whose access has been granted to PUBLIC.
If they need additional access, then more
privileges can be granted using the GRANT statement. See the
GRANT reference page for a complete list of
privileges you can grant to users and service accounts. Run GRANT from the
command line.
Replace the following:
USERNAME: the email address for the user. You must use quotes
around the email because it contains special characters (@ and
.)
TABLE_NAME: the name of the table that you want to give the user
access to.
grantselectonTABLE_NAMEto"USERNAME";
Grant database privileges to an IAM group
When you use IAM group authentication, you grant database privileges to IAM
groups instead of granting privileges to individual users or service accounts.
By default, when you add an IAM group to a Cloud SQL instance,
the group has no database privileges.
To give the database privileges to IAM group, use the GRANT statement.
After they log in to the Cloud SQL instance for the first time, each group member
(including users and service accounts) inherit the database privileges granted
to the group automatically.
Replace the following:
GROUP_NAME: the email address of the
Cloud Identity group, including the @ and the domain name. For example,
if the IAM group's email address is
example-group@example.com, then the group name is
example-group@example.com.
You must use quotes around the group name because the string contains
special characters (@ and
.)
TABLE_NAME: the name of the table that you want to give the user
access to.
Run GRANT from the psql command line.
grantselectonTABLE_NAMEto"GROUP_NAME";
For more information about granting privileges, see the
GRANT reference page in the PostgreSQL documentation.
The database privileges that you grant to the IAM group take
effect immediately.
View IAM users, service accounts, and groups added to a Cloud SQL instance
To view the IAM users, service accounts, and groups that have
been added to your Cloud SQL instance, run the following commands.
Console
In the Google Cloud console, go to the Cloud SQL Instances page.
To open the Overview page of an instance, click the instance name.
Select Users from the SQL navigation menu.
The page displays a list of IAM users, service accounts,
and Cloud Identity groups that have been added to your instance.
Optional: To view a list of IAM users or service accounts
that have already logged in to the instance, click Authenticated IAM group
members.
gcloud
Replace INSTANCE_NAME with the name of the instance that has the
groups you want to view.
gcloudsqluserslist--instance=INSTANCE_NAME
Groups have a user type of CLOUD_IAM_GROUP.
Groups display whether they are active or inactive with the IAM_STATUS
column. An ACTIVE IAM group can be used for IAM
group authentication. An INACTIVE IAM group can't be
used for IAM group authentication.
The output also lists user and service accounts on
your Cloud SQL instance.
User accounts that are members of a group have the type of
CLOUD_IAM_GROUP_USER.
Service accounts that are members of a group have the type
CLOUD_IAM_GROUP_SERVICE_ACCOUNT.
User accounts that are individual IAM database authentication user accounts have the type of
CLOUD_IAM_USER.
Service accounts that are individual IAM database authentication service accounts have the type
of CLOUD_IAM_SERVICE_ACCOUNT.
REST v1
The following request uses the
users.list method to list the users who have accounts on the Cloud SQL
instance.
Before using any of the request data,
make the following replacements:
PROJECT_ID: the project ID
INSTANCE_ID: the instance ID
HTTP method and URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID/users/list
To send your request, expand one of these options:
Groups display whether they are active or inactive through the iamStatus
field. An ACTIVE IAM group can be used for IAM
group authentication. An INACTIVE IAM group is not used for
IAM group authentication.
The value IAM_STATUS_UNSPECIFIED for the iamStatus
field means that IAM status isn't relevant for that particular
user type.
The output also lists user and service accounts on
your Cloud SQL instance.
User accounts that are members of a group have the type of
CLOUD_IAM_GROUP_USER.
Service accounts that are members of a group have the type
CLOUD_IAM_GROUP_SERVICE_ACCOUNT.
User accounts that are individual IAM database authentication user accounts have the type of
CLOUD_IAM_USER.
Service accounts that are individual IAM database authentication service accounts have the type
of CLOUD_IAM_SERVICE_ACCOUNT.
REST v1beta4
The following request uses the
users.list method to list the users who have accounts on the Cloud SQL
instance.
Before using any of the request data,
make the following replacements:
PROJECT_ID: the project ID
INSTANCE_ID: the instance ID
HTTP method and URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID/users/list
To send your request, expand one of these options:
Groups display whether they are active or inactive through the iamStatus
field. An ACTIVE IAM group can be used for IAM
group authentication. An INACTIVE IAM group can't be used for
IAM group authentication.
The value IAM_STATUS_UNSPECIFIED for the iamStatus
field means that IAM status isn't relevant for that particular
user type.
The output also lists user and service accounts on
your Cloud SQL instance.
User accounts that are members of a group have the type of
CLOUD_IAM_GROUP_USER.
Service accounts that are members of a group have the type
CLOUD_IAM_GROUP_SERVICE_ACCOUNT.
User accounts that are individual IAM database authentication user accounts have the type of
CLOUD_IAM_USER.
Service accounts that are individual IAM database authentication service accounts have the type
of CLOUD_IAM_SERVICE_ACCOUNT.
Remove an individual IAM user or service account from a Cloud SQL instance
To remove an individual user or service account that is not a member of a group
from the Cloud SQL instance, you delete that account by using the following command:
Console
In the Google Cloud console, go to the Cloud SQL Instances page.
Remove IAM group members from a Cloud SQL instance
There are two ways to remove IAM group members from a
Cloud SQL instance:
Automatic removal
Manual removal
Automatic removal
To remove an IAM group member, you need to remove
their membership from the applicable IAM groups in
Cloud Identity. After the IAM group users have
lost membership to all the applicable groups in Cloud Identity,
Cloud SQL removes those group users from the instance automatically.
The only exception to this removal are group
users who own database objects. These group users must be manually removed.
Changes to group membership, such as the addition or removal of a member, take
about 15 minutes to propagate. The 15 minute propagation delay from
Cloud SQL happens in parallel with the time required for IAM changes to propagate.
Manual removal
In cases where an IAM group user can't be removed automatically,
you can manually remove them. You can't manually remove an IAM
group user from a Cloud SQL instance by using gcloud CLI,
Google Cloud console, Terraform, or the Cloud SQL Admin API. Instead, database users with superuser privileges can manually
delete IAM group users from the Cloud SQL instance
using a DROP USER statement from a
PostgreSQL client.
After you manually
remove an IAM group user from the Cloud SQL instance,
make sure that you also remove them from the IAM group in
Cloud Identity to prevent further logins to the Cloud SQL
instance.
Change the domain name for existing IAM group members on a Cloud SQL instance
If you change the domain name of an organization in Cloud Identity,
then the changes aren't applied automatically to IAM group members
on the Cloud SQL instance.
For example, if you change user@example.com to user@new-example.com in Cloud Identity,
then user@example.com remains on the Cloud SQL instance despite the
domain name being changed in Cloud Identity.
To change the domain name of the IAM group members, do the following:
You can delete the added IAM groups from
the Cloud SQL instance. After you delete an
IAM group from the instance, all users and
service accounts that belong to the IAM group
lose any database privileges that were granted to the IAM
group. In addition, the following conditions apply:
The users and service accounts that belong to the IAM
group are still able to log in until the
cloudsql.instances.login IAM permission
is removed from the group.
If the deletion of a group results in the IAM group user
or service accounts belonging to no other groups on the instance,
then Cloud SQLremoves the IAM group user
or service accounts from the instance.
However, if an IAM group user owns a database object
on the instance, then you must reassign ownership of the object
before you can drop the user manually.
If you delete all IAM groups from a Cloud SQL
instance, then all the IAM group users and service accounts
lose all their database privileges. In addition, the following conditions apply:
All IAM group users and service accounts are unable to
login to the instance.
Cloud SQL also removes all IAM group users and
service accounts from the instance automatically.
However, if an IAM group user owns a database object
on the instance, then you must reassign ownership of the object
before you can drop the user manually.
Console
In the Google Cloud console, go to the Cloud SQL Instances page.
GROUP_NAME: the first part of the email address of the
Cloud Identity group. For
example, using the email address
example-group@example.com,
the Cloud Identity group name is example-group.
INSTANCE_NAME: the name of the Cloud SQL instance with the
Cloud Identity group you want to delete.
If you delete an IAM group from IAM or
Cloud Identity but don't delete the IAM group from the
Cloud SQL instance, then the IAM group is marked as
INACTIVE and remains on the instance until you
remove the group manually.
Inactive IAM groups can't be used for IAM group
authentication. Database privileges granted to inactive groups don't get passed
on to their members. Inactive groups don't count as valid IAM
group memberships. IAM group users that don't belong to an
active IAM won't be able to authenticate using IAM
group authentication.
If an IAM group is inactive, then the group remains inactive
on the Cloud SQL instance even if you recreate the group in
IAM and Cloud Identity. To recreate the
IAM group name, do the following:
Grant database privileges to the newly created IAM group.
Remove IAM login permissions from an IAM group
If you revoke the cloudsql.instanceUser role from an IAM group,
then all members of the group lose the ability to log in to any Cloud SQL
instance in the project. The users or service accounts can only log into
instances if they are members of another IAM group that
still has login permissions.
IAM group members such as users or service accounts can be
removed from the IAM group in Cloud Identity.
After the removal has propagated through IAM, the user can
no longer log in to the database unless they have
received login permissions from another group or
are directly granted login privileges. In addition, users removed from a
group lose the database privileges of the group.
If an IAM group user doesn't belong to any groups on the instance, then
Cloud SQL automatically removes the user from
the instance.
However, if Cloud SQL
detects that an IAM group user owns an object on the instance,
then Cloud SQL doesn't remove the user.
An administrator must reassign ownership of the object and manually remove the user.
View login information in audit logs
You can enable audit logs to capture IAM logins to the database.
When there are login issues, you can use the audit logs to diagnose the problem.
When an attempt to log in fails, PostgreSQL returns a minimal error message for
security reasons. For example:
PGPASSWORD=not-a-password psql --host=... --username=... --dbname=...
psql: error: could not connect to server: FATAL: Cloud SQL IAM user authentication failed for user "..."
FATAL: pg_hba.conf rejects connection for host "...", user "...", database "...", SSL off
You can review the PostgreSQL error logs for more details about the error. For
more information, see
Viewing Logs.
For example, for the previous error, the following log entry explains the action
you can take to resolve the problem.
F ... [152172]: [1-1] db=...,user=... FATAL: Cloud SQL IAM user authentication failed for user "..."
I ... [152172]: [2-1] db=...,user=... DETAIL: Request is missing required authentication credential. Expected OAuth 2 access token, log in cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
Check the error message you receive. If the message does not indicate that you
used "Cloud SQL IAM user authentication" or
"Cloud SQL IAM service account authentication," verify that
the database user type used to log in is either CLOUD_IAM_USER or
CLOUD_IAM_SERVICE_ACCOUNT.
You can use the Google Cloud console or the gcloud sql
users list command to check this.
For an IAM user, verify that the database username is the
IAM user's email.
If you used IAM database authentication, check the details of the error message. You can find the
error message in the database error log. If it indicates the access token (OAuth
2.0) you sent as a password was invalid, you can use the
gcloud auth application-default print-access-tokengcloud command to find details of the token, as follows:
Verify that the token is for the intended IAM user or service
account and has not expired.
If the details indicate a lack of permission, then verify the IAM
user or service account is granted the cloudsql.instances.login permission using
the predefined Cloud SQL Instance User role or custom role in the
IAM policy of the instance's project. Use the IAM
Policy Troubleshooter for additional help.
If a login fails due to IAM database authentication unavailability, the user can log in using the
default PostgreSQL user and password. This method of logging in still gives the
user access to the entire database. Verify that the connection is a secured
connection.
Troubleshoot user accounts that use IAM group authentication
This section lists troubleshooting scenarios for IAM group authentication.
Failure to add a group to a database
When you attempt to add a group to an instance, you receive the
following error:
(gcloud.sql.users.create) HTTPError 400: Invalid request: Provided CLOUD_IAM_GROUP: EMAIL, does not exist.
Make sure the email address that you provided is a valid group.
Verify that the account is a member of the group
added to the Cloud SQL instance.
List the users and service accounts on the instance.
gcloudsqluserslist--instance=INSTANCE_NAME
In the output, check whether the user or service account is listed as a
CLOUD_IAM_USER or a CLOUD_IAM_SERVICE_ACCOUNT.
If the user or service account is listed as a
CLOUD_IAM_USER or a CLOUD_IAM_SERVICE_ACCOUNT,
then remove the account from the instance. The account you are removing is
an individual IAM account which doesn't inherit database
privileges of the group.
Log in again to the instance with the user or service account.
Logging in again to the instance re-creates the account with the correct
account type of CLOUD_IAM_GROUP_USER or
CLOUD_IAM_GROUP_SERVICE_ACCOUNT.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-12-10 UTC."],[],[]]
icon
appears next to the username.