This page provides information about Identity and Access Management (IAM) rolesand permissions and how they're used with Cloud SQL instances.

Introduction

This page focuses on aspects of IAM that are relevantspecifically to Cloud SQL. For a detailed discussion ofIAM and its features generally, seeIdentity and Access Management. Inparticular, see theManaging IAM Policies section.IAM lets you control who has access to theresources in your Google Cloud project. The set of access rules you apply to aresource is called an IAMpolicy. An IAM policyapplied to your project defines the actions that users can take on all resourceswithin your project.

Members are the "who" of IAM. Members can be individual users,groups, domains, or even the public as a whole. Members are assignedroles,which grant members the ability to perform actions in Cloud SQL aswell as Google Cloud more generally. Each role is a collection of one ormorepermissions. Permissions are the basic units of IAM: eachpermission lets you perform a certain action. SeeIAM roles in Cloud SQLandIAM permissions in Cloud SQLfor complete lists of all the roles and permissions available in Cloud SQL.

When you use an account to connect to a Cloud SQLinstance, the account must have theCloud SQL > Client role (roles/cloudsql.client), whichincludes thepermissionsrequired for connecting.

You can add roles to an account in the Console on theIAM & Admin > IAM page, and see which permissions belong to which roles on theIAM & Admin > Rolespage.

Cloud SQL uses service accounts for authentication between Cloud SQLand other Google Cloud products. Service accounts providecredentials inJSON format, which you download from the Console and use for authenticationin various scenarios.

Cloud SQL roles and permissions with Cloud SQL Auth Proxy

If you are connecting to a Cloud SQL instance from a Compute Engineinstance usingCloud SQL Auth Proxy,you can use the default Compute Engine service account associated with theCompute Engine instance.

As with all accounts connecting to a Cloud SQL instance, the serviceaccount must have theCloud SQL > Client role.

Cloud SQL roles and permissions with serverless options

Use a service account to authorize access from these options. The serviceaccount authorizes access to all Cloud SQL in a specific project. When youcreate an application or a Cloud Run functions, this servicecreates this account for you. You can find the account on theIAM & Admin > IAM page, with the appropriate suffix:

Serverless option	Service account suffix
App Engine	@gae-api-prod.google.com.iam.gserviceaccount.com
Cloud Run functions	@appspot.gserviceaccount.com
Cloud Run	compute@developer.gserviceaccount.com

As with all accounts connecting to a Cloud SQL instance, the serviceaccount must have theCloud SQL > Client role.

Cloud SQL roles and permissions with Cloud Storage

The import and export features in Cloud SQL work together. Exportswrite to Cloud Storage and imports read from there. For this reason, theservice account you use for these operations needs both read and writepermissions to Cloud Storage:

• To import data to, and export data from, Cloud Storage, the Cloud SQLinstance's service account must have thestorage.objectAdminIAM role set in the project. Youcan find the instance's service account name in the Google Cloud console on yourinstance'sOverview page.
• You can use thegcloudstorage buckets add-iam-policy-binding command to grant thisIAM roleto the service account for the bucket.
• For help with setting IAM roles and permissions, seeUsingIAM permissions.
• For more information,seeIAM for Cloud Storage.

Cloud SQL roles and permissions for Dataplex Universal Catalog integration

To provide access to Cloud SQL metadata on Dataplex Universal Catalog, youcan grant a user theroles/cloudsql.schemaViewer role or add thecloudsql.schemas.view permission to a custom role.

For more information, seeManage Cloud SQL resources with Dataplex Universal Catalog.

Cloud SQL roles and permissions with other scenarios

Cloud SQL interacts with other Google Cloud products and tools.These interactions also require specific roles and permissions which can varybetween scenarios. Cloud SQL documentation provides detailedinformation about these requirements for each case below:

• Using customer-managed encryption keys (CMEK).
• IAM Roles for Administering VPC Service Controls.

Use IAM with projects

The following sections show how to complete basic IAM tasks onprojects.

To complete the following tasks, you must have theresourcemanager.projects.getIamPolicy andresourcemanager.projects.setIamPolicy IAM permissions.

Add a member to a project-level policy

For a list of roles associated with Cloud SQL,seeIAM Roles.

View the IAM policy for a project

Remove a member from a project-level policy

Important: It typically takes about a minute for revoking access to takeeffect. In some cases it may take longer. If you remove a user's access,this change is immediately reflected in the metadata; however, the user maystill have access to the object for a short period of time.

Best practices

IAM, like any other administrative settings, requires activemanagement to be effective. Before you make a resource accessible toother users, be sure you know what roles you want each of those people to play.Over time, changes in project management, usage patterns, and organizationalownership may require you to modify IAM settings on projects,especially if you manage Cloud SQL in a large organization or for alarge group of users. As you evaluate and plan your access control settings,keep the following best practices in mind:

• Use the principle of least privilege when granting access.Theprinciple of least privilege is a security guidelinefor granting access to your resources. When you grant access based on theprinciple of least privilege, you give a user only the access they need toaccomplish their assigned task.

• Avoid granting roles withsetIamPolicy permission to people you do not know.GrantingsetIamPolicy permission allows a user to change permissionsand take control of data. You should use roles withsetIamPolicypermission only when you want to delegate administrative control overobjects and buckets.

• Be sure you delegate administrative control of your resources.You should be sure that your resources can still be managed byother team members should an individual with administrative access leave thegroup. Two common ways to achieve this are the following:

  • Assign theCloud SQL Admin role for your project to a groupinstead of an individual.
  • Assign theCloud SQL Admin role for your project to at least twoindividuals.

What's next

• Learn more aboutControlling access