This page describes how to use Identity and Access Management (IAM) to manage access to your AlloyDB databases.
IAM authentication concepts
When using IAM authentication, permission to access an AlloyDB instance isn't granted directly to the end user. Instead, permissions are grouped into roles, and roles are granted to principals. For more information, see the IAM overview.
Administrators who have users sign in through IAM database authentication can use IAM to centrally manage access control to their instances using IAM policies.
IAM policies involve the following entities:
Principals. In AlloyDB, you can use a user account or a service account (for applications). For more information, see Principals.
Roles. For IAM database authentication, a principal requires the alloydb.instances.login permission. This permission is included in the AlloyDB Client role (
roles/alloydb.client). To get this permission, you bind the user, service account, or group to the predefined role or a custom role that includes the permission. For more information, see Permission and roles.Resource. The resources that principals access are AlloyDB instances. By default, IAM policy bindings are applied at the project-level, such that principals receive role permissions for all AlloyDB instances in the project. For more information, see Resources.
Compare database authentication options
Use the following table to help you decide which authentication method is the best fit for your use case.
| Feature | Built-in database authentication | IAM database authentication (individual) |
|---|---|---|
| Authentication method | Password | Temporary authentication token |
| Network traffic encryption | SSL not required | SSL required |
| User management | Manual | Centralized through IAM |
Automatic versus manual IAM database authentication
AlloyDB offers two methods for IAM database authentication: automatic and manual.
Automatic IAM database authentication
Automatic IAM database authentication lets you hand off requesting and managing access tokens to an intermediary AlloyDB connector, such as the Auth Proxy or one of the Language Connectors.
With automatic IAM database authentication, an application needs to pass only the IAM database username in a connection request from the client. The connector submits the access token information for the password attribute on behalf of the client.
Manual IAM database authentication
Manual IAM database authentication requires the IAM principal to explicitly pass the access token for the password attribute in the client connection request. Principals must first sign in to Google Cloud and explicitly request the access token from IAM.
IAM conditions and audit logs
IAM conditions lets you grant roles based on a variety of attributes. For example, you can allow access only at certain dates and times or grant access only to AlloyDB resources with certain names.
To keep records of data access, including sign-ins, you can use Cloud Audit Logs. Cloud Audit Logs is turned off by default. You need to turn on Data Access audit logs for sign-in tracking.
Restrictions and best practices
For security, sign-ins using IAM database authentication are only available on an SSL connection. Unencrypted connections are rejected.
There is a per-minute sign-in quota for each instance, which includes both successful and unsuccessful sign-ins. When the quota is exceeded, sign-ins are temporarily unavailable. We recommend that you avoid frequent sign-ins and restrict sign-ins using authorized networks.