Determine Identity and Access Management (IAM) and policies for database connectivity and access control

Secure connectivity and authentication mechanisms determine how applications reach Google Cloud databases and prove their identity before any data moves. AlloyDB (opens in a new tab) and Cloud SQL use Identity and Access Management (IAM) to authorize who can connect and log in, while encrypted tunnels and private network paths protect data in transit. Together, authentication, encryption, and private connectivity keep database instances off public networks and limit exposure to authorized networks and identities.

1.1Database Authentication Methods

Database authentication methods in AlloyDB and Cloud SQL fall into two models: built-in database authentication and IAM database authentication. Built-in authentication uses a database username and password stored in the database, with access controlled by GRANT and REVOKE statements inside the database. IAM database authentication uses IAM principals such as users, groups, and service accounts, and it relies on IAM roles plus database privileges so the same Google identity controls both cloud and database access.

IAM database authentication reduces password sprawl because users sign in with existing Google Account credentials instead of separate database passwords. Access uses short-lived OAuth 2.0 access tokens that are valid for only one hour, which lowers the risk if credentials leak. Centralized control also brings consistent policies across projects, simpler user and role management, and automatic account creation on first login when IAM group authentication is used.

1.2Encrypted Connections with Proxies and Connectors

Encrypted connectors create a secure tunnel between the application and the database instance and upgrade traffic to modern encryption. The AlloyDB Auth Proxy is a client-side proxy process that transparently 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 for Cloud SQL by calling APIs through sqladmin.googleapis.com and handling tokens for the client.

AlloyDB automatically generates the server certificate for TLS 1.3 encryption between the instance and clients, and Google applies default protections for data in transit. To use client certificates for mutual authentication, the connection must use an AlloyDB Language Connector, which uses mutual TLS (mTLS) authentication, or the AlloyDB Auth Proxy. Both AlloyDB connectors use IAM to authorize the connection and protect it with mTLS, with an option to configure passwordless authentication instead of IAM authentication.

The three connector choices differ in form factor and how they secure traffic:

Automatic IAM database authentication is the most reliable choice for long-lived processes and connection pooling because the connector requests and refreshes short-lived tokens without operator action. Manual IAM database authentication requires the principal to sign in to Google Cloud, explicitly request an OAuth 2.0 token with the Cloud SQL Admin API scope with the gcloud CLI, and pass the email address 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 instead.

1.3Private Network Paths and 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 AlloyDB directly with serverless workloads such as Cloud Run, so traffic flows from the serverless environment through the VPC connector to the private database endpoint.

Broader network controls add boundaries around those private paths. VPC Service Controls 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, and Cloud VPN or Cloud Interconnect provides a secure, reliable path between a corporate network and Google Cloud for hybrid applications. 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 Connection and Login

IAM permissions for connection and login separate the right to connect to 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, while roles/cloudsql.client contains the cloudsql.instances.connect permission required to connect through the Cloud SQL Auth Proxy. An IAM user, service account, or group 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 application workloads can connect when the Auth Proxy or Language Connectors are used, and 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 so each group receives only the connect and login permissions it needs. 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.

IAM role mapping and least privilege enforcement is the practice of giving each user, group, or workload only the permissions it needs for databases and nothing more. Identity and Access Management (IAM) controls this access by binding a principal to a role on a resource, and the policy applies from the point where it is granted downward. Because a project-level grant applies to all instances, clusters, or databases in that project, the level and role chosen directly determine how broadly database access spreads.

2.1Principals and Resource Scope

Principals in IAM are the identities that receive database access, and every database access decision starts by identifying the principal. IAM policies for databases can be granted at the organization, folder, or project level, and access flows downward from the level where the binding is created. A binding at the project level grants permissions on all database resources in that project, while an organization-level binding grants visibility and control across all projects and databases in the organization.

The four principal types are:

• Users: individual human identities, such as user:alice@example.com, authenticated through Cloud Identity, Google Workspace, or a federated identity provider.
• Groups: collections of users managed in a directory, such as database operators or application developers, 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 on your behalf.

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

2.2Predefined, Custom, and Basic Roles

Database IAM roles define which permissions a principal receives, and choosing the narrowest role is how least privilege is enforced. Database Center (opens in a new tab) illustrates a predefined product role with roles/databasecenter.viewer, which grants view access to all instances in projects where Database Center is enabled, and the optional roles/recommender.viewer, which adds view access to recommender-related health issues. Predefined roles package the permissions needed for a specific job, while custom roles let administrators combine only the exact permissions a team or workload requires.

The tradeoff is simplicity against precision: basic roles are easy but grant far more than database tasks need, while custom roles take more design but minimize blast radius. In production environments, service accounts and users must receive a predefined role or custom role that meets their needs instead of Owner, Editor, or Viewer. Additional privileges for related features, such as Gemini in Databases or Security Command Center recommendations, are granted separately so the base database role stays narrow.

2.3Assigning Roles to Users and Groups

Role assignment to groups is the scalable way to enforce least privilege for people who access databases. IAM best practice is to create separate functional groups for each job, such as database administrators, developers, and operators, and grant the required roles to the group rather than to individual users. Individual grants increase complexity and make auditing harder, while group membership can be added, reviewed, and removed through existing identity processes.

Granting access follows an ordered workflow in which the IAM policy on the resource is updated to bind the principal to a role:

1. Confirm authority and target: An administrator with sufficient authority, such as Owner or Project IAM Admin (roles/resourcemanager.projectIamAdmin), opens the IAM page and confirms the target resource.
2. Add principals and roles: The administrator adds the new principals and selects the role to assign, adding another role only when a second job function is required.
3. Save the binding: The administrator saves the binding, after which the principal can act only with the permissions contained in that role.

Least privilege is maintained over time by modifying or removing bindings as jobs change. An administrator finds the existing principal, opens edit access to add a new role or delete an unneeded role, and saves the updated policy to immediately change what the principal can do. To remove access completely, the administrator selects the principal and removes the binding, which revokes all permissions that flowed from that grant.

2.4Service Accounts and Workload Access

Service accounts provide least-privilege database access for workloads, and workload access depends on two separate bindings. The service account itself must first receive a resource role, such as a database viewer or client role, that defines what the workload can do to databases and project resources. 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.

Data and control flow from the identity to the workload to the database in a fixed order:

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 when it calls Google Cloud APIs.

Authorization for the API is separate from authorization for the data inside the database. IAM controls access to the database resource, such as the instance, cluster, agent, or conversation object, while access to the underlying data queried through that resource is controlled by permissions on the data source itself. This boundary means a workload can be allowed to reach a database API without automatically receiving rights to all data the database contains.

2.5Privileged Access With Groups and Impersonation

Privileged database and infrastructure access uses a temporary elevation pattern that keeps standing permissions narrow. In this pattern, 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. The privileged service account depends on the project IAM policy for its power, and humans depend on a group binding to use it.

Access flows from group membership to impersonation to privileged action. An administrator creates a Google group for elevation, such as elevated-compute-access, and grants the group Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) plus Service Account Token Creator (roles/iam.serviceAccountTokenCreator) on the privileged service account. A member of the group then impersonates the service account for the period of membership, so the powerful role is exercised only while the user belongs to the group. Removing the user from the group ends the ability to impersonate without changing the service account itself.

This design enforces least privilege because broad power lives in one auditable service account instead of many human accounts. Administrators enable Cloud Audit Logs for IAM policy changes and data access, including ADMIN_READ, DATA_READ, and DATA_WRITE where supported, so every grant and every use of privileged access can be reviewed. Organization policies such as Restrict Resource Service Usage (constraints/gcp.restrictServiceUsage) and Resource Location Restriction (constraints/gcp.resourceLocations) add a perimeter boundary by limiting which services and locations databases and related services can use.

Context-aware access and auditability combines precise, conditional access to database resources with complete logging to prove who accessed what. Identity and Access Management (IAM) (opens in a new tab) grants the base permission to a principal, conditions and context limit when and where that permission works, and Cloud Audit Logs records both data access and permission changes for review. Together they enforce least privilege for databases while supporting security compliance.

3.1Time-Bound and Resource-Specific Access with IAM Conditions

Time-bound and resource-specific access means an IAM grant works only for a limited period or for a specific database resource instead of standing access to everything. Privileged database access should either expire automatically or be reviewed periodically, so temporary membership replaces permanent admin rights. A common pattern separates identity from privilege: an administrator creates a Google group such as elevated-compute-access, creates a service account that holds the admin role such as roles/compute.admin, and grants group members only the ability to impersonate that service account through roles/iam.serviceAccountTokenCreator and roles/serviceusage.serviceUsageConsumer.

Implementing this delegated pattern follows an ordered dependency where each step depends on the previous one:

1. Create privileged group: Create a Google group for privileged database or project access and manage membership through the identity provider.
2. Create privileged service account: Create a service account and bind the admin role to the service account, not directly to users.
3. Delegate impersonation: Grant the group impersonation rights on the service account so members act through the service account only while they are members.
4. Enable audit logging: Enable Cloud Audit Logs for the relevant API so every use of the elevated privilege is logged for review and analysis.

In this flow, access moves from the user to group membership to service account impersonation to the target instance or database. Removing the user from the group removes the privilege without changing the resource policy, which keeps standing access narrow.

3.2Context-Based Controls with Access Context Manager

Access Context Manager provides fine-grained, attribute-based access control that adds a context check on top of an IAM role. An IAM role decides what a principal is allowed to do, while an access level decides whether the request context is trusted enough to allow it. For example, an access level can require that users must be on the corporate network when using privileged access to resources, which blocks the same privileged identity from connecting from an untrusted location.

This creates a trust boundary with the corporate network and Google Cloud on opposite sides, and the policy enforces the crossing condition at request time. Strong authentication supports the same goal by verifying identity before context is evaluated. Enable single sign-on for federated identities and enforce 2-step verification, also called multi-factor authentication, for all users with privileged access to resources. Use Fast IDentity Online (FIDO) security keys for highly privileged and emergency-access accounts because they provide phishing-resistant verification.

3.3Monitoring and Auditing Database Access with Cloud Audit Logs

Cloud Audit Logs is the auditing system that records administrative activity, data reads, data writes, and IAM policy changes for Google Cloud resources. Administrators enable data access audit configuration for a service with log types ADMIN_READ, DATA_READ, and DATA_WRITE, so read and write patterns on databases and related APIs are available for review and analysis. Administrators can then analyze privileged access requests and access patterns in Logs Explorer, detect anomalies, and export logs to persist them as necessary for audit purposes.

IAM changes themselves are also auditable through the same logs. Filtering Cloud Audit Logs for SetIamPolicy operations shows recent additions, removals, or modifications to IAM permissions that might explain a loss of access or an unexpected grant. This separates two questions: data access logs show who read or wrote data, while SetIamPolicy entries show who changed who is allowed to access it. Review both together to verify that time-bound access actually expired and that resource-specific grants were not widened.

Key Facts

• IAM database authentication for AlloyDB and Cloud SQL uses short-lived OAuth 2.0 tokens valid for one hour instead of long-lived database passwords.
• The Cloud SQL Auth Proxy requires both cloudsql.instances.connect to connect and cloudsql.instances.login to log in with IAM database authentication.
• Private Service Connect must be configured when the AlloyDB cluster is created to allow private IP access from another Virtual Private Cloud (VPC).
• Basic roles Owner, Editor, and Viewer must not be used for routine database work in production; predefined or custom roles enforce least privilege.
• Cloud Audit Logs uses DATA_READ and DATA_WRITE to audit database use and SetIamPolicy entries to audit who changed IAM permissions.