Determine database connectivity and access management considerations

1.1Database Authentication Models

Database authentication models for AlloyDB and Cloud SQL (opens in a new tab) define how a client proves its identity before it can connect. Built-in database authentication uses a username and password stored inside the database, with access controlled by GRANT and REVOKE statements. Identity and Access Management (IAM) (opens in a new tab) database authentication uses Google identities such as users, groups, and service accounts, with IAM roles plus database privileges controlling access.

IAM database authentication reduces password sprawl because users sign in with existing Google Account credentials. Access uses short-lived OAuth 2.0 tokens valid for only one hour, which limits damage if a token leaks. Centralized IAM control also provides consistent policies across projects, simpler role management, and automatic account creation on first login when IAM group authentication is used.

1.2Encrypted Tunnels with Auth Proxies and Connectors

Encrypted tunnels with Auth Proxies and connectors protect traffic between the application and the database instance and upgrade it to modern encryption. The AlloyDB Auth Proxy is a client-side proxy process that upgrades non-TLS connections to TLS 1.3 connections. AlloyDB Language Connectors are in-application client libraries that connect from the application to a proxy server on the AlloyDB cluster. The Cloud SQL Auth Proxy and Cloud SQL connectors for Go, Java, and Python follow the same pattern by calling APIs through sqladmin.googleapis.com.

AlloyDB automatically generates the server certificate for TLS 1.3 between the instance and clients. To use client certificates for mutual authentication, the connection must use an AlloyDB Language Connector with mutual TLS (mTLS) or the AlloyDB Auth Proxy. Both AlloyDB options authorize the connection with IAM using mTLS, with an option for passwordless authentication. Automatic IAM database authentication is the most reliable choice for long-lived processes and pooling because the connector requests and refreshes one-hour tokens without operator action.

The three connector choices differ in form factor and security:

Manual IAM database authentication requires the principal to sign in to Google Cloud, request an OAuth 2.0 token with the Cloud SQL Admin API scope using the gcloud CLI, and pass the email as username and the token as password. Manual connections expire after one hour, and context-aware access configurations cannot use a Cloud SQL connector with IAM database authentication and must connect directly.

1.3Private Network Paths and Security Perimeters

Private network paths keep database traffic inside Google Cloud and off public networks by using private IP addresses and controlled entry points. Private services access and Private Service Connect connect an application in another Virtual Private Cloud (VPC) to AlloyDB using its private IP address, and Private Service Connect must be configured when the AlloyDB cluster is created. Serverless VPC Access connects serverless workloads such as Cloud Run to AlloyDB, so traffic flows from the serverless environment through the VPC connector to the private database endpoint.

Broader controls add boundaries around those private paths. VPC Service Controls (opens in a new tab) defines a service perimeter around database resources to control data movement with ingress and egress rules and prevent exfiltration. Shared VPC provides centralized network configuration while keeping environments separated. Cloud VPN or Cloud Interconnect provides a secure path between a corporate network and Google Cloud for hybrid applications, with the corporate network on one side of the boundary and Google Cloud on the other. If public IP is enabled, access should be limited with AlloyDB Language Connectors and a custom organization policy that restricts fields such as enable public IP address.

1.4IAM Permissions for Connecting and Logging In

IAM permissions for connecting and logging in separate the right to reach the instance from the right to log in as a database user. For Cloud SQL, the predefined role roles/cloudsql.instanceUser contains the cloudsql.instances.login permission required to log in with IAM database authentication. The role roles/cloudsql.client contains the cloudsql.instances.connect permission required to connect through the Cloud SQL Auth Proxy. An identity that uses the proxy therefore needs both roles, and a new database user has no database privileges by default until privileges are granted with database roles or GRANT commands.

For AlloyDB, IAM controls which workloads can connect when the Auth Proxy or Language Connectors are used, while IAM database authentication controls which principals can log in. Administrators should grant required roles to functional groups rather than to individual users and follow least privilege. Outbound firewall and network rules must also allow egress TCP to port 443 for API calls and port 3307 for Cloud SQL connector data traffic, since the API domain does not have a fixed IP address.

1.5Principals, Roles, and Least Privilege Scope

Principals, roles, and resource scope determine how broadly database access spreads in IAM. An IAM policy binds a principal to a role on a resource, and the policy applies from the point where it is granted downward. A project-level grant applies to all instances, clusters, or databases in that project, while an organization-level grant applies across all projects in the organization.

IAM policies for databases use four principal types:

• Users: individual human identities, such as user:alice@example.com, authenticated through Cloud Identity, Google Workspace, or a federated provider.
• Groups: collections of users, such as database operators, that let administrators grant and audit access once for many people.
• Domains: all users in an organization domain, which grants broad access and is rarely appropriate for databases.
• Service accounts: application identities, such as serviceAccount:app-sa@project.iam.gserviceaccount.com, including service agents that Google creates to let a service access resources.

For fleet tools such as Database Center, organization-level permissions are recommended when principals must view all database resources, while project-level permissions limit access to one project's instances.

Database IAM roles package permissions at different levels of precision:

Basic roles are simple but grant far more than database tasks need, while custom roles take more design but minimize blast radius. Additional privileges for features such as Gemini in Databases are granted separately so the base database role stays narrow.

1.6Service Accounts, Groups, and Privileged Access

Service accounts, groups, and impersonation provide least-privilege access for workloads and administrators. A service account itself must first receive a resource role that defines what the workload can do to databases. Then the human or group that manages the workload must receive permission on the service account, typically Service Account User (roles/iam.serviceAccountUser), which allows that principal to attach the service account to a compute resource.

Workload access follows a fixed order where each step depends on the previous one:

1. Create the service account: The service account is created in the project that owns the workload.
2. Grant the resource role: The project owner binds the least-privilege resource role to the service account identity.
3. Delegate use permission: The owner binds the use permission to the administrator who will deploy the workload.
4. Attach and run: Only after both bindings exist can the administrator create the resource, such as a Compute Engine instance with the service account attached, and the running code authenticates as that service account.

Privileged human access uses the same separation. The control plane manages a privileged service account that holds a powerful role such as Compute Admin (roles/compute.admin), while no human holds that role directly. An administrator creates a group such as elevated-compute-access and grants the group Service Usage Consumer plus Service Account Token Creator on the privileged service account. A member then impersonates the service account while a member of the group, so removing the user from the group ends the privilege without changing the service account. IAM controls access to the database resource, while access to data inside the database is controlled by permissions on the data source itself.

1.7Conditional Access and Audit Logging

Conditional access and audit logging combine time-bound grants, context checks, and complete logs to enforce least privilege. Time-bound access means a grant works only for a limited period or for a specific resource instead of standing access to everything. A common pattern separates identity from privilege by holding admin power in a service account and granting users only temporary impersonation rights through group membership.

Access Context Manager adds a context check on top of an IAM role. The IAM role decides what a principal is allowed to do, while an access level decides whether the request context is trusted enough. For example, an access level can require users to be on the corporate network when using privileged access, which blocks the same identity from connecting from an untrusted location. Strong authentication supports the same goal through single sign-on, 2-step verification for privileged users, and Fast IDentity Online (FIDO) security keys for highly privileged accounts.

Cloud Audit Logs records administrative activity, data reads, data writes, and IAM policy changes. Administrators enable data access audit configuration with log types ADMIN_READ, DATA_READ, and DATA_WRITE to review database use in Logs Explorer and export logs for retention. Filtering for SetIamPolicy operations shows who changed who is allowed to access resources. Data access logs therefore show who read or wrote data, while SetIamPolicy entries show who changed permissions, and reviewing both verifies that time-bound access actually expired.

2.1SSL/TLS Encryption and Network Controls for Cloud SQL

SSL/TLS encryption and network controls for Cloud SQL (opens in a new tab) protect data moving between database clients and database instances. Cloud SQL encrypts and authenticates all data in transit at one or more network layers when data moves outside physical boundaries controlled by Google or on behalf of Google. Data in transit inside a Google-controlled physical boundary is generally authenticated but might not be encrypted by default, so internal traffic may still need SSL based on threat model.

Clients reach a Cloud SQL for PostgreSQL instance through an authorized static IP address with a PostgreSQL client or through Cloud SQL Proxy, and both paths still benefit from transit encryption. SSL can be configured for intra-zone connections when internal traffic also requires encryption. Because encryption at rest with 256-bit Advanced Encryption Standard (AES-256) or better is automatic, SSL/TLS closes the remaining gap for data moving over networks.

2.2Control-Plane Auditing with Cloud Audit Logs

Control-plane auditing with Cloud Audit Logs answers who did what, where, and when for Google Cloud resources. For Cloud SQL, Cloud Audit Logs audit administrative and maintenance operations done on an instance, such as creating users, changing instance settings, and enabling IAM database authentication. Login information for IAM database users can be viewed in audit logs, which helps identify failed logins and unauthorized access attempts.

Centralized auditing depends on collecting the right logs and keeping them long enough for review. Sharing audit logs from Cloud Identity brings user login events from the Google Admin console into Google Cloud for central management. Enabling Data Access audit logs increases visibility into reads, while exporting logs to a log sink supports long-term storage for compliance. Access Transparency logs record access by Google support and engineering personnel alongside Access Approval, which requires explicit approval before Google employees access data.

2.3Inside-Database Auditing by Engine

Inside-database auditing by engine records SQL operations performed inside the database, which Cloud Audit Logs alone do not capture. The engine mechanism depends on the database type, so PostgreSQL and MySQL use different tools to track data manipulation language (DML) and data definition language (DDL) activity. Together, Cloud Audit Logs show control-plane changes to the instance, while engine logs show what users did inside tables.

The audit mechanism maps to each engine as follows:

For MySQL, retention for these logs should be managed according to business needs. For PostgreSQL, pgAudit tracks statement-level operations needed to review user activity. This separation matters because an instance-level log cannot prove which rows or statements a user touched inside the database.

2.4Mapping IAM Login to Database Privileges

Mapping IAM login to database privileges requires two separate grants because IAM and the database engine enforce different layers. IAM verifies identity with an access token and checks the cloudsql.instances.login permission on the instance. The MySQL or PostgreSQL engine then checks its own GRANTs or roles on databases, tables, and columns. A principal who can log in but has no database privileges still cannot read or write data.

Access is provisioned in an ordered sequence where the instance depends on the IAM allow policy for connection and the data depends on the engine grant for use:

1. Enable IAM database authentication: Turn on IAM database authentication on the Cloud SQL instance so the instance accepts IAM access tokens.
2. Grant the IAM login role: Bind the user, service account, or group to a role containing cloudsql.instances.login.
3. Add the identity to the instance: Create the IAM user, service account, or group as a database user on that specific instance.
4. Grant database privileges: Assign only the needed database privileges or database roles inside the engine.

IAM authorization itself is built from principals, roles, and resources. Permissions are grouped into roles, roles are granted to principals through an allow policy, and effective permissions are the union of all roles. A Cloud SQL IAM binding applied at the project level gives permissions on all instances in that project by inheritance, so scoping to the lowest needed level is central to least privilege. Legacy basic roles Owner, Editor, and Viewer grant access across Google Cloud rather than only for Cloud SQL and must be avoided for database-only access.

2.5Individual Versus Group IAM Management

Individual versus group IAM management describes two ways to scope who can obtain an IAM database token for Cloud SQL and AlloyDB (opens in a new tab). Individual IAM authentication adds specific users or service accounts to the cluster or instance, which gives precise control for a few accounts but grows harder to maintain as teams change. Group IAM authentication adds a Cloud Identity group once, and all members inherit both the IAM login permission and database privileges.

Group membership controls access through inheritance. When a user joins a group that already has login permission, the user gains the ability to sign in and automatically inherits database privileges granted to the group. AlloyDB creates a database account on first sign-in, while Cloud SQL creates the account after first login, and each person still signs in with individual credentials so audit logs show which account acted. When a user leaves the group, the user loses inherited privileges, although propagation takes time. A Cloud SQL instance supports a maximum of 200 IAM groups, Cloud Identity membership changes take about 15 minutes to propagate plus IAM propagation time, and an account cannot exist as both an individual IAM user and a group member on the same instance.

The credential options compare as follows:

Layered granularity in BigQuery follows the same least-privilege idea. A role granted on an organization, folder, or project applies to all BigQuery resources inside it, while a dataset-level role provides access to only that dataset. Finer grants can target tables, views, routines, connections, saved queries, and pipelines. A principal who needs only one dataset therefore receives a dataset-level role rather than a project-level role.

2.6Automatic Versus Manual Token Handling and Choosing Authentication

Automatic versus manual token handling describes two ways to deliver the temporary IAM token to the database. With automatic IAM database authentication, a connector requests and manages tokens on behalf of the client, so the application passes only the IAM database username and the connector submits the token in the password field. With manual authentication, the principal signs in to Google Cloud, explicitly requests the token, and passes the token as the password with the email address as username.

The connector path depends on the service but follows the same flow from client to IAM to database. For Cloud SQL, automatic authentication requires a Cloud SQL connector such as the Auth Proxy or Go, Java, or Python connectors. For AlloyDB, automatic authentication uses the AlloyDB Auth Proxy or an AlloyDB Language Connector, which authorizes with IAM and protects traffic with mTLS. Because OAuth 2.0 tokens expire after one hour, new manual connections fail unless a fresh token is supplied, so automatic authentication is strongly recommended for long-lived processes and pooling. If context-aware access is used, a connector cannot be used with IAM database authentication and the client must connect directly.

Choosing authentication means matching lifecycle and scale to the workload. Built-in database authentication (opens in a new tab) uses a password managed inside the engine with GRANT or REVOKE, does not require SSL, and needs manual rotation per instance. IAM database authentication (opens in a new tab) uses short-lived tokens, requires an SSL connection, and centralizes management through IAM. A principal needs alloydb.instances.login for AlloyDB, included in roles/alloydb.client, or cloudsql.instances.login for Cloud SQL. For Cloud SQL, IAM access also depends on the cloudsql_iam_authentication flag for MySQL or cloudsql.iam_authentication flag for PostgreSQL. Choose built-in for small stable sets of database-local or legacy password logins, individual IAM for a few audited users, and group IAM when teams change often.

Key Facts

• IAM database authentication for AlloyDB and Cloud SQL uses short-lived OAuth 2.0 tokens valid for one hour and requires an SSL or TLS 1.3 connection.
• The Cloud SQL Auth Proxy requires both cloudsql.instances.connect to connect and cloudsql.instances.login to log in, and login alone grants no data privileges without engine-level grants.
• Private Service Connect must be configured when the AlloyDB cluster is created to allow private IP access from another Virtual Private Cloud (VPC).
• A Cloud SQL instance supports a maximum of 200 IAM groups, and Cloud Identity membership changes take about 15 minutes to propagate plus IAM propagation time.
• Cloud Audit Logs record administrative operations on the instance, while pgAudit for PostgreSQL and slow-query, general, and error logs for MySQL record SQL operations inside the database.