Recommended Google Cloud Authentication Patterns for Production Applications

Production workloads should rely on short-lived, automatically-rotated identities with tightly scoped permissions rather than long-lived static credentials.

The google/skills repository establishes concrete authentication patterns for Google Cloud Platform (GCP) production environments. According to the guidance in [skills/cloud/google-cloud-recipe-auth/SKILL.md](https://github.com/google/skills/blob/main/skills/cloud/google-cloud-recipe-auth/SKILL.md), production applications must eliminate service account JSON keys from source control and instead use attached service accounts, workload identity federation, or native metadata server tokens.

Custom Service Accounts for GCP Resources

Attach a dedicated custom service account to any compute resource running production code, including Compute Engine VMs, Cloud Run services, Cloud Functions, or GKE pods.

When you specify a service account at creation time, the GCP metadata server automatically supplies short-lived OAuth 2.0 access tokens to the workload. No credential files reside on the instance, and tokens rotate automatically every hour.

Deploy a Cloud Run service with a custom service account using the following YAML configuration:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    spec:
      serviceAccountName: my-prod-sa@my-project.iam.gserviceaccount.com

Inside the container, the Google Cloud client libraries automatically retrieve tokens from the metadata server at http://metadata.google.internal. The Python example below demonstrates retrieving a valid access token using Application Default Credentials (ADC):

import google.auth
import google.auth.transport.requests

credentials, project_id = google.auth.default()
request = google.auth.transport.requests.Request()
credentials.refresh(request)
access_token = credentials.token

Workload Identity Federation for External Workloads

Use Workload Identity Federation when connecting workloads running outside GCP—such as AWS, Azure, on-premises data centers, or non-GKE Kubernetes clusters—to Google Cloud resources.

This pattern exchanges external identity provider tokens (AWS IAM roles, Azure AD, or generic OIDC) for Google access tokens via the IAM Service Account Credentials API. No service account keys are ever materialized on external infrastructure.

Configure Workload Identity Federation using Terraform as follows:

resource "google_service_account" "aws_federated" {
  account_id   = "aws-federated"
  display_name = "AWS federated SA"
}

resource "google_iam_workload_identity_pool" "aws_pool" {
  provider = google
  workload_identity_pool_id = "aws-pool"
}

resource "google_iam_workload_identity_pool_provider" "aws_provider" {
  workload_identity_pool_id = google_iam_workload_identity_pool.aws_pool.id
  provider_id               = "aws"
  attribute_mapping = {
    "google.subject" = "assertion.sub"
    "attribute.aws_role" = "assertion.aws_role"
  }
  oidc {
    issuer_uri = "https://sts.amazonaws.com"
  }
}

Service Account Impersonation for Development and CI/CD

Implement Service Account Impersonation for local development or continuous integration pipelines where human developers need elevated privileges without holding permanent keys.

The developer authenticates with their personal identity using gcloud auth login, then configures the CLI to impersonate a dedicated service account:

gcloud auth login
gcloud config set auth/impersonate_service_account my-prod-sa@my-project.iam.gserviceaccount.com
gcloud auth application-default login

The auth/impersonate_service_account configuration directs ADC to fetch short-lived tokens on behalf of the target service account rather than using the developer's personal credentials directly.

Application Default Credentials (ADC)

Application Default Credentials provide seamless authentication for client libraries (Python, Go, Java, Node.js) without code changes across environments.

ADC follows a search order:

1. Checks the GOOGLE_APPLICATION_CREDENTIALS environment variable (if set)
2. Falls back to the attached service account token from the metadata server on GCP resources

This pattern ensures identical code runs locally (with impersonation) and in production (with attached service accounts).

Secure API Key Management

Use Restricted API Keys only for public-facing services such as Maps, Vertex AI Express, or mobile endpoints where full service account authentication is unnecessary.

Create keys in the Google Cloud Console, then applystrict restrictions:

• Limit to specific APIs and methods
• Bind to allowed IP ranges, HTTP referrers, or mobile apps
• Store keys in Secret Manager, never in source control

OIDC ID Tokens for Service-to-Service Authentication

When one Cloud Run service calls another private Cloud Run service—or any HTTP endpoint protected by Identity-Aware Proxy (IAP)—use OIDC ID Tokens instead of access tokens.

The caller obtains a token via the metadata server and includes it in the Authorization: Bearer header. The receiver validates the token's audience (aud) claim and issuer.

TOKEN=$(curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://my-target.run.app)
curl -H "Authorization: Bearer $TOKEN" https://my-target.run.app/endpoint

Summary

• Never store service account JSON keys in source control or VM images; rely on attached service accounts or Workload Identity Federation.
• Apply least-privilege IAM roles (e.g., roles/storage.objectViewer rather than broad roles/editor).
• Leverage short-lived credentials from the metadata server or IAM Credentials API, which rotate automatically.
• Use impersonation for CI/CD pipelines to avoid embedding keys while maintaining audit trails.
• Validate OIDC tokens for service-to-service communication within serverless architectures.

Frequently Asked Questions

What is the recommended authentication method for a Cloud Run production service?

Attach a custom service account to the Cloud Run service during deployment. The Cloud Run sidecar automatically injects short-lived tokens into the container environment, eliminating the need for credential files. Client libraries use ADC to retrieve these tokens automatically from the metadata server.

How do I authenticate workloads running in AWS or Azure to Google Cloud APIs?

Configure Workload Identity Federation by creating a workload identity pool and provider in Google Cloud that trusts your external identity provider. Exchange the external identity token for a Google access token via the IAM Service Account Credentials API without exporting service account keys.

Should I use service account JSON keys in production?

No. Service account JSON keys represent long-lived credentials that increase the attack surface if leaked. Production applications should use attached service accounts on GCP resources, Workload Identity Federation for external resources, or ADC with impersonation for local development.

What is Application Default Credentials and when should I use it?

Application Default Credentials is a strategy used by Google Cloud client libraries to automatically discover credentials from the environment. Use ADC when you want identical authentication code to work across local development (with GOOGLE_APPLICATION_CREDENTIALS or impersonation) and production (with metadata server tokens) without conditional logic.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}