Prepare and test your skills
Prepare and test your skills
Secure Database Connectivity and Identity Federation connects applications to Cloud SQL and AlloyDB over encrypted, IAM-authorized paths without storing long-lived passwords or key files. Cloud SQL Auth Proxy (opens in a new tab) and AlloyDB Auth Proxy (opens in a new tab) create the secure tunnel, Identity and Access Management (IAM) controls who can use it, and Workload Identity Federation (WIF) (opens in a new tab) lets workloads outside Google Cloud get short-lived credentials without service account keys.
The AlloyDB Auth Proxy is a client-side proxy that builds a secure TCP tunnel from an application to an AlloyDB instance. The application connects to the proxy on localhost with a plain connection, and the proxy upgrades that connection to Transport Layer Security (TLS) 1.3 toward AlloyDB. AlloyDB Language Connectors are client libraries that perform the same function inside application code by connecting to a proxy server on the AlloyDB cluster.
Traffic flows from the application to the local proxy or connector, then from the proxy or connector to the AlloyDB primary instance. Both options use IAM to authorize the connection and use mutual TLS (mTLS) to protect traffic, with an option for passwordless authentication. AlloyDB automatically generates the server certificate for TLS 1.3, but client certificates for mutual authentication are only available when the proxy or a Language Connector is used. Choose the Auth Proxy when a sidecar process is preferred, such as in Google Kubernetes Engine (GKE), and choose a Language Connector when the application should embed the secure connection in its database driver.
Database authentication in AlloyDB verifies the database user after the secure tunnel is established. AlloyDB supports built-in database authentication with a username and password, where authorization is controlled with GRANT and REVOKE statements. AlloyDB also supports IAM database authentication with IAM principals such as users and service accounts, which the Language Connectors can automate.
| Method | Credential used | How access is controlled |
|---|---|---|
| Built-in database authentication | Long-lived username and password stored by the application | PostgreSQL GRANT and REVOKE on databases and schemas |
| IAM database authentication | Existing Google Account or service account with short-lived access tokens | IAM roles and database grants tied to the IAM principal |
IAM authentication centralizes control and reduces separate database passwords. It provides unified access control across databases and other Google Cloud resources, lets users sign in with existing Google Account credentials, and uses short-lived access tokens that reduce the risk from leaked passwords.
Authorization for proxy connections controls which workloads are allowed to reach the database instance. The Cloud SQL Auth Proxy must authenticate as a Cloud SQL IAM identity to authorize connections to a Cloud SQL instance. That identity is normally a service account whose credential file is explicitly linked to the proxy process while the proxy is running, and the same file can be duplicated into a system image when multiple machines need their own proxy.
The service account depends on the cloudsql.instances.connect permission to open the tunnel. The predefined Cloud SQL roles that include this permission are Cloud SQL Client, Cloud SQL Editor, and Cloud SQL Admin, while legacy project roles require at least Editor. Creating the service account itself requires the resourcemanager.projects.setIamPolicy permission, so a project owner may need to create it. For AlloyDB, IAM likewise controls which workloads can connect through the Auth Proxy or Language Connectors, and administrators prepare a specific IAM principal for proxy authorization following the principle of least privilege.
Exam tip: A proxy service account fails without cloudsql.instances.connect, so grant Cloud SQL Client, Editor, or Admin; use version 1.12 or later of the Cloud SQL Auth Proxy when connecting over private IP.
Running an auth proxy in production means treating the proxy as part of application availability. If the Cloud SQL Auth Proxy process stops, all existing connections through it drop and the application cannot create new database connections through the proxy. The proxy also issues requests to the Cloud SQL Admin API that count against project quota, with the highest usage at startup and then about 2 API calls per hour per connected instance while running.
systemd, upstart, supervisor, or a Windows Service wrapper.On the Google side, AlloyDB runs under a Google-managed service account named service-PROJECT_NUMBER-gcp-sa-alloydb-iam.gserviceaccount.com. AlloyDB resources such as the PostgreSQL server use that service account, which acts with the privileges of the AlloyDB service agent to manage infrastructure.
Private network paths keep database traffic inside Google Cloud or inside a hybrid private connection instead of the public internet. AlloyDB instances use private IP addresses by default, and the AlloyDB API endpoint is not publicly routable unless public IP is explicitly enabled. Additional controls place a trust boundary around the data: Virtual Private Cloud (VPC) Service Controls creates a service perimeter that blocks requests from outside the perimeter, Shared VPC centralizes network management while separating environments, and custom organization policies can restrict who may enable public IP.
Connections from applications to AlloyDB can stay private through several paths. Private Service Connect or private services access connects an application in another VPC using the AlloyDB private IP address, with Private Service Connect configured when the cluster is created. Serverless VPC Access connects Cloud Run directly to AlloyDB, while Cloud VPN or Cloud Interconnect provides the private, encrypted path between a corporate network and Google Cloud. If public IP is enabled, combine Language Connectors with a custom organization policy on fields such as enable public IP address to limit exposure.
Workload Identity Federation (WIF) is keyless authentication that lets workloads on external clouds or on-premises obtain short-lived Google credentials by presenting their external identity. The external workload federates through an identity provider linked to Cloud Identity or Google Workspace, Google verifies that external identity, and the workload receives temporary credentials for Google Cloud APIs and database connectors. Those temporary credentials then authenticate the Cloud SQL Auth Proxy or AlloyDB Auth Proxy to IAM, so no downloaded service account key file is stored in configuration files, images, or repositories.
This model removes the main risk of service account keys, where the key value persists in local files and CLI configuration and can be copied by anyone with access to the environment. Administrators enforce the shift by restricting key creation with the constraints/iam.disableServiceAccountKeyCreation organization policy and by using federated identities for both human and workload access. Choose WIF for production workloads outside Google Cloud, reserve credential files for cases where federation is not possible, and always grant the federated or service account identity only the database connect and data permissions it needs.
Token-Based Authorization and Identity Management uses short-lived tokens to prove identity and grant API access without sharing long-lived passwords or keys. The most common short-lived service account credentials are OAuth 2.0 (opens in a new tab) access tokens and OpenID Connect (OIDC) (opens in a new tab) ID tokens, and customer-facing sign-in is managed by Identity Platform (opens in a new tab). An authentication profile in Application Integration stores these details once so multiple integrations can reuse the same connection to an external application, service, or data source.
OAuth 2.0 access tokens are credentials issued by an authorization server to a calling client for authorizing API calls. Data flows from the client to the authorization server to request a token, and then from the client to the API with the token in the HTTP Authorization request header in the Authorization: TYPE CREDENTIALS format. The authorization server can be a standalone server or an API that issues credentials, and scopes define the access permissions carried by the token. Choose an OAuth 2.0 access token when the API must check what the caller is allowed to do, because scopes limit that permission.
An OAuth 2.0 configuration depends on four related values that connect the integration to the authorization server. The authentication endpoint redirects the user to review access permissions, and the token endpoint grants or refreshes the access token only after access is granted. The client ID is a unique string that identifies the application to Google's OAuth servers and is not a secret, while the secret is a shared key between the client and the authorization server that must stay confidential. Scope values are separated by a single space when multiple permissions are requested.
OpenID Connect (OIDC) ID tokens are JSON Web Token (JWT) credentials that prove the identity of a service account to a specific recipient. The Google OIDC provider, accounts.google.com, signs and issues these JWTs using a service account, and the token flows from the issuing service to the destination API where the audience is validated. The audience identifies the recipients that the JWT is intended for, so a token issued for one backend cannot be reused by another. Choose an OIDC ID token when the backend must verify who the caller is and that the token was created for that backend.
An OIDC configuration depends on the service account acting as the caller identity and the audience of the destination. The service account is a principal in the Google Cloud project with permission to access the API, such as a Cloud Function trigger URL used as the audience for a Cloud Function task. The integration service depends on the Service Account Token Creator role granted to service-PROJECT_NUMBER@gcp-sa-integrations.iam.gserviceaccount.com to create these tokens. Without that role binding, the service cannot sign OIDC tokens on behalf of the configured service account.
| Token | What it carries | Key configuration |
|---|---|---|
| OAuth 2.0 access token | Authorization to call an API with specific scopes | Authentication endpoint, token endpoint, client ID, secret, scope(s) |
| OIDC ID token | Authentication as a service account for a specific recipient | Service account issued by accounts.google.com, audience identifying the recipient |
Exam tip: Use scopes to limit an OAuth 2.0 token to specific permissions, and use the audience to bind an OIDC ID token to one recipient such as a trigger URL.
JSON Web Token (JWT) authentication defined by RFC7519 uses a signed token built from a header, a payload, and a shared secret. The JWT header specifies the signature algorithm, and only HS256 is supported in this configuration. The JWT payload carries a set of claims, which can use registered, public, or custom claims to describe the caller and constraints. The secret is a shared key between the client and the authentication server, with an optional SSL/TLS certificate and private key when the server requires mutual transport security.
The generic auth token type sends the same credential pattern directly in the request without an OAuth exchange. Credentials travel from the client to the server in the Authorization: TYPE CREDENTIALS header, where the type is a scheme such as Basic, Bearer, or MAC. The token field holds the credential for that scheme, and an SSL/TLS certificate and private key are uploaded only when the authentication server requires them. Use this type when the destination expects a static bearer or basic credential rather than a Google-issued OAuth or OIDC token.
Identity Platform is the Google-grade authentication service for adding user sign-in and credential management to apps and services. Multi-tenancy extends Identity Platform by creating tenants, which are unique silos of users and configurations within a single Identity Platform project. These silos might represent different customers, business units, or subsidiaries, and the pattern is most commonly used in business-to-business (B2B) apps. Traffic flows from each tenant's users to the shared project, but identity data and policy stay isolated on the tenant side of the boundary.
Each Identity Platform tenant establishes a data isolation boundary and operates autonomously from other tenants in the same project. A tenant owns its own isolated resources:
Because each tenant has separate providers, users, and quota, one customer can use email and password while another uses federation without affecting the other tenant. Identity Platform tenants support many of the same sign-in methods as non-tenant instances, including email and password, social providers such as Google, Microsoft, and LinkedIn, Security Assertion Markup Language (SAML) federation, and OpenID Connect federation. Tenants do not support disabling account linking or adding a blocking function specific to a given tenant. User signup and user deletion also cannot be disabled from the Google Cloud console, although both settings can be configured through the API.
Programmatic Authentication and Application Default Credentials lets the same application code authenticate in development and production without changing how it finds credentials. Application Default Credentials (ADC) (opens in a new tab) is a strategy used by authentication libraries to automatically find credentials based on the application environment. The authentication libraries make those credentials available to Google Cloud client libraries (opens in a new tab) and Google API Client Libraries. ADC cannot be used to authenticate the gcloud CLI itself, and it cannot be used with an API key, which works only with specific APIs.
ADC discovery is an ordered credential search that lets workloads stay portable across environments. Libraries that implement ADC check known locations in the environment where they run, so moving code from local development to production only changes which credentials are present, not the code. The search order does not indicate which option is most secure or preferred.
GOOGLE_APPLICATION_CREDENTIALS environment variable: ADC first checks this variable for the path to a credential JSON file.gcloud auth application-default login.If ADC finds usable credentials earlier in the order, it uses them and does not continue to later sources. For production on Google Cloud, the preferred source is the attached service account, even though it is checked last.
The GOOGLE_APPLICATION_CREDENTIALS environment variable supplies ADC with a JSON credential file for federated identities or service accounts. This approach is useful for workloads outside Google Cloud that need access to Google Cloud resources, including existing systems integrated through federation. The file pointed to by the variable determines which identity ADC presents to Google Cloud APIs.
Service account keys create a security risk and are not recommended because a compromised key can be used by a bad actor without any additional information. Prioritize IAM-integrated identities, such as an attached service account or Workload Identity Federation, over downloading and storing static JSON keys.
Exam tip: ADC checks GOOGLE_APPLICATION_CREDENTIALS first, but the attached service account remains the preferred production identity on Google Cloud; search order does not equal best practice.
The local ADC file provides credentials for development on a local device or in Cloud Shell. Running gcloud auth application-default login creates application_default_credentials.json in a well-known location, which is $HOME/.config/gcloud/application_default_credentials.json on Linux and macOS and %APPDATA%\gcloud\application_default_credentials.json on Windows. These ADC credentials are distinct from gcloud CLI credentials used by gcloud commands, and Cloud Shell already provides credentials so the login step is not needed there.
Local setup normally follows gcloud init and then gcloud auth application-default login, which opens a sign-in screen and stores user credentials for ADC. By default, access tokens from a local ADC file created with user credentials include the cloud-wide scope https://www.googleapis.com/auth/cloud-platform. Explicit scopes can be supplied with the --scopes flag, OAuth scopes outside Google Cloud such as Google Drive can use an OAuth client ID with the --client-id-file flag, and service account testing can use impersonation with the --impersonate-service-account flag.
Service account impersonation lets local code act with a service account's permissions without holding its key. Impersonation requires the iam.serviceAccounts.getAccessToken permission, which is included in the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator). The gcloud CLI can impersonate for its own calls with gcloud config set auth/impersonate_service_account SERVICE_ACCT_EMAIL, while creating a local ADC file with impersonation is supported only for the Go, Java, Node.js, and Python client libraries.
The attached service account is the IAM-integrated identity used to authenticate a workload running on Google Cloud. When ADC finds no credentials in the environment variable or local file, it uses the metadata server to obtain short-lived credentials for the service account attached to the compute resource, such as a Compute Engine virtual machine (VM) instance. Because the platform manages these credentials, no static key file is stored with the application.
For most Google Cloud services, the service account must be attached when the resource is created and cannot be added or replaced later. Compute Engine is an exception because it lets an operator attach a service account to a VM instance at any time.
GOOGLE_APPLICATION_CREDENTIALS file first, then local ADC file from gcloud auth application-default login, then attached service account via the metadata server.cloudsql.instances.connect permission, granted by Cloud SQL Client, Editor, or Admin roles.OAuth 2.0 access tokens carry scopes for authorizing API calls, while OpenID Connect ID tokens are JSON Web Token credentials that prove service account identity to a specific audience. Choose an OAuth 2.0 access token when the API must check what the caller is allowed to do, and choose an OIDC ID token when the backend must verify who the caller is and that the token was created for that backend.
Application Default Credentials first checks the GOOGLE_APPLICATION_CREDENTIALS environment variable for a credential JSON file, then checks the local ADC credential file created by gcloud auth application-default login, then queries the metadata server for the service account attached to the Google Cloud resource. If usable credentials are found earlier in the order it uses them and does not continue, but the attached service account remains the preferred production identity on Google Cloud because the platform manages short-lived credentials with no stored key file.
Use Workload Identity Federation for production workloads outside Google Cloud because it lets external workloads present their external identity to obtain short-lived Google credentials without storing a downloaded service account key file. Those temporary credentials then authenticate the Cloud SQL Auth Proxy or AlloyDB Auth Proxy to Identity and Access Management, which removes the risk of key values persisting in local files and configuration.
Last updated