Authentication & Secrets

CI authentication requires non-interactive credentials. Personal Google account OAuth is interactive — it opens a browser for consent — and cannot work in headless CI environments. The two viable options are API key authentication (set GOOGLE_API_KEY as a GitHub secret) and service account authentication (a Google Cloud service account with Gemini API access). API keys are simpler to set up but cannot leverage organization-level quotas or IAM policies. Service accounts integrate with Google Cloud IAM for granular access control.

Secret management in CI follows the principle of least privilege. Store the API key or service account JSON as a repository secret (Settings → Secrets → Actions). Reference it in the workflow via ${{ secrets.SECRET_NAME }}. Never echo secrets to logs — even masked, they can leak through error messages or debug output. Rotate API keys on a schedule and immediately after any suspected exposure. Use OIDC federation with Google Cloud Workload Identity for the most secure setup — no long-lived credentials at all.

# Option 1: API Key (simplest)
- name: Gemini analysis
  env:
    GOOGLE_API_KEY: ${{ secrets.GOOGLE_API_KEY }}
  run: gemini -p "Analyze src/ for issues" --output-format json

# Option 2: Service Account (enterprise)
- name: Authenticate with Google Cloud
  uses: google-github-actions/auth@v2
  with:
    credentials_json: ${{ secrets.GCP_SA_KEY }}

- name: Gemini analysis
  run: gemini -p "Analyze src/ for issues" --output-format json

# Option 3: Workload Identity Federation (most secure, no secrets)
- name: Authenticate via OIDC
  uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: projects/123/locations/global/workloadIdentityPools/github/providers/repo
    service_account: gemini-ci@project.iam.gserviceaccount.com

- name: Gemini analysis
  run: gemini -p "Analyze src/ for issues" --output-format json