Providers / Google Cloud
Cloud
Google Cloud API keys and credentials
What every Google Cloud credential a founder holds does, whether it expires, and what tends to break. Each fact links to Google Cloud's own docs.
At a glance
| Credential | Expiry | Permissions |
|---|---|---|
| Google account login for Cloud Console | Not documented | – |
| Service account key (JSON or P12) | You choose, max 90 days | Can be scoped |
| OAuth client secret | Not documented | Full access only |
| API key | Not documented | Can be scoped |
Each credential
Google account login for Cloud Console
- Not documented
Console access uses a Google account, so its sign-in and 2-Step Verification settings apply.
Service account key (JSON or P12)
- You choose, max 90 days
- Can be scoped
- Expiry readable by API
Service account keys do not expire by default. The org policy constraint constraints/iam.serviceAccountKeyExpiryHours sets how long newly created keys stay valid; allowed values (ALLOW only) are 1h, 8h, 24h, 168h, 336h, 720h, 1440h and 2160h, so the longest enforceable expiry is 2160h (90 days). It can be set on a project, folder or organization and cannot be merged with a parent policy. Docs warn it can cause outages if workloads rely on existing keys. Up to 10 keys per service account. The key resource carries validAfterTime and validBeforeTime. Permissions come from IAM roles on the service account.
OAuth client secret
- Not documented
- Full access only
Rotation is done by adding a second secret, moving the app to it, then disabling the old one. Apps created earlier can keep using old secrets. A third-party source says the full value is visible only at creation and that clients inactive for six months are deleted; neither was confirmed on an official Google page.
API key
- Not documented
- Can be scoped
Keys can be restricted by API (which APIs the key can call) and by application (websites, IP addresses or apps). The console and gcloud require at least one API restriction. Keys created through the REST API are unrestricted unless a restriction is specified. The docs describe no expiry or rotation schedule.
What usually goes wrong
- Service account key is created and never rotated, and a leaked key keeps working
- Organization key-expiry policy is enabled and a key stops working at its validity end, breaking deployments
- Unrestricted API key is exposed in client code and used against billable APIs
- OAuth client secret is rotated without migrating the app, so sign-in breaks after the old secret is disabled
Renewals and billing
Cloud Billing REST reference lists no method that returns incurred cost (billingAccounts, projects.getBillingInfo, services, SKUs). Actual cost data comes from the Detailed usage cost export to BigQuery. Export is not backfilled for supported-region datasets (multi-region EU or US backfills current and previous month).
Where to find it in Google Cloud
- Open Google Cloud credentials
- Open Google Auth Platform clients
- Edit the OAuth client's authorized redirect URIs
- Google OAuth 2.0 web server guide
What Google Cloud's docs don't say
We couldn't confirm these from official docs, so don't rely on them either way:
- Whether API keys expire
- Google account session expiry
- Billing model and budget alert behavior
Rotating or replacing a Google Cloud key
The steps are the same for most providers: make the new key, deploy it everywhere the old one is used, check it works, then revoke the old one. Our guides walk through it:
Sources
- docs.cloud.google.com/iam/docs/creating-managing-service-account-keys
- docs.cloud.google.com/docs/authentication/api-keys
- docs.cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts
- docs.cloud.google.com/billing/docs/reference/rest
- docs.cloud.google.com/billing/docs/how-to/export-data-bigquery
Related providers
Keep track of every Google Cloud key
StackHangar stores your Google Cloud keys in an encrypted vault, grouped by the product they belong to, warns you before they expire, and walks you through rotating them. We can't read your secrets.