Service Account Configuration

Service accounts are the identity layer for non-human access to Google Cloud. When Gemini CLI runs in CI/CD or automates cloud operations, it acts as a service account — not as your personal Google identity. The principle of least privilege applies aggressively: create dedicated service accounts for Gemini CLI workflows with only the IAM roles they need. A CI review bot needs roles/viewer and roles/cloudbuild.builds.viewer. A deployment bot needs roles/run.admin and roles/iam.serviceAccountUser. Never use the default compute engine service account.

Service account impersonation is the modern alternative to key files. Instead of downloading a JSON key (which can be leaked, committed to Git, or stolen), grant your human identity the roles/iam.serviceAccountTokenCreator role on the target service account. Then use gcloud auth application-default login --impersonate-service-account=SA_EMAIL to generate temporary credentials that expire automatically. This eliminates persistent key files entirely.

# Create a dedicated service account for Gemini CI
gcloud iam service-accounts create gemini-ci \
  --display-name="Gemini CLI CI/CD" \
  --description="Scoped service account for Gemini CLI automation"

# Grant minimum required roles
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:gemini-ci@my-project.iam.gserviceaccount.com" \
  --role="roles/run.admin"

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:gemini-ci@my-project.iam.gserviceaccount.com" \
  --role="roles/cloudbuild.builds.viewer"

# Impersonation instead of key files (local dev)
gcloud auth application-default login \
  --impersonate-service-account=gemini-ci@my-project.iam.gserviceaccount.com

# Gemini CLI now operates with the service account's permissions
# but credentials expire automatically — no key file to leak