How do I get credentials to integrate google' cloud TTS in livekit ?

Thanks for reaching out, Shriniket. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

is there any other way apat froms service account, as google says it's riskt

Good question — you don't have to use a downloaded service-account key file. Options that avoid long‑lived key files: • Workload Identity Federation (recommended): lets your LiveKit agent obtain short‑lived Google credentials from an external IdP (AWS, Azure, OIDC) without ever storing a JSON key. Use this if your agent runs outside GCP. • Run on GCP with an attached service account: deploy the agent to Cloud Run, GKE, or Compute Engine and assign a service account to the instance. No key file required and Google client libraries pick up credentials automatically. • Service account impersonation with least privilege: avoid broad permissions by creating a low‑privilege service account and have a short‑lived principal impersonate it (combine with workload identity where possible). Not viable for LiveKit TTS: • API keys — Google Cloud TTS does not support API‑key authentication. • User OAuth (3‑legged) — impractical for unattended backend agents. If you tell me where you run your LiveKit agent (AWS, Azure, on‑prem, or GCP) I can give exact setup steps for Workload Identity Federation or for attaching a GCP service account to your deployment. Sources: examples/voice_agents | livekit/livekit_composite | DeepWiki | Gemini Realtime Agent with Live Vision | LiveKit docs | TTS Comparison | LiveKit docs

it's on AWS

Great — since you're on AWS, the safest option is Workload Identity Federation so your LiveKit agent can get short‑lived Google credentials without a JSON key file. Below are concise steps you can follow. 1. Create a Google Cloud service account • In Google Cloud Console, create a service account with only the TTS permissions it needs. 1. Create a Workload Identity Pool & Provider (GCP) • In IAM → Workload Identity Pools, create a pool (e.g., livekit-pool). • Add an OIDC provider that trusts AWS STS. Use the provider type “AWS” or OIDC with AWS as the issuer; note the provider requires your AWS account ID and the AWS role's ARN you’ll create next. 1. Create an AWS IAM role for your LiveKit agent • In AWS IAM, create a role assumed by AWS services where your agent runs (EC2, ECS task, or EKS service account). • Add a trust relationship allowing sts:AssumeRoleWithWebIdentity or the AWS principal to assume the role from your workload identity provider. • Attach any minimal AWS policies needed for your deployment (not for GCP access). 1. Allow GCP service account to be impersonated • In GCP IAM, grant the Workload Identity Pool (or the specific provider) the permission to impersonate the service account: ◦ Grant the role

roles/iam.workloadIdentityUser

on the service account to the AWS principal identifier in the pool (format provided by GCP when you create the provider). 1. Configure your LiveKit agent to fetch tokens • Use Google Cloud client libraries which support Workload Identity Federation. • Instead of

GOOGLE_APPLICATION_CREDENTIALS

, configure the federation by setting environment variables or a credentials config that points to your workload identity pool and provider. The libraries will exchange AWS STS tokens for short‑lived Google access tokens. 1. Verify TTS calls • Run the agent and confirm application calls to Cloud TTS succeed. The Google library should show it’s using federated credentials (short‑lived). If you want, I can provide: • Exact IAM trust JSON and example AWS role policy for your runtime (ECS, EC2, or EKS). • The exact `gcloud`/console commands or the JSON config snippet to set up the Workload Identity Provider and bind

roles/iam.workloadIdentityUser

. Which runtime are you using on AWS (EC2, ECS/Fargate, or EKS)?