GCP
TokenTimer scans a Google Cloud project for expiring secrets and certificates. Secrets come from Secret Manager (REST API v1). Certificates come from Certificate Manager (global-location certificates) and Compute Engine sslCertificates (global and regional load-balancer certificates).
Project ID: your GCP project ID (for example my-project-123456)
Credential setup
Paste a short-lived Cloud Shell access token, not a service-account JSON key.
gcloud auth print-access-token
That token belongs to the account you are logged in as. Roles you granted to a service account apply only if you impersonate it:
gcloud auth print-access-token --impersonate-service-account=SA_EMAIL
Revoke after use on a one-time scan. The token is used once and never stored unless you explicitly set up Enterprise auto-sync for this provider.
A token minted after a cloud-platform login carries the scopes the scan needs. A token limited to the https://www.googleapis.com/auth/secretmanager scope can list secrets but cannot call Certificate Manager or Compute Engine.
What to scan
The GCP import form has two independent checkboxes. Tick at least one before you scan:
| Checkbox | What it calls |
|---|---|
| Secrets (on by default) | Secret Manager secrets and their enabled versions |
| Certificates (off by default) | Certificate Manager certificates at locations/global, plus Compute Engine sslCertificates across global and every reachable region |
Certificates are opt-in so a secrets-only token is not forced to call APIs it was never granted. You can scan secrets, certificates, or both in one request.
Permissions required
Grant these IAM roles on the project to the identity that minted the token (your user, or the impersonated service account):
| Role | When |
|---|---|
roles/secretmanager.viewer | Secrets checkbox |
roles/certificatemanager.viewer | Certificates checkbox |
roles/compute.viewer | Certificates checkbox |
roles/secretmanager.secretAccessor is not sufficient on its own: it reads secret values but cannot list secrets.
Enable the matching APIs on the project before the first scan:
- Secret Manager API (
secretmanager.googleapis.com) - Certificate Manager API (
certificatemanager.googleapis.com) - Compute Engine API (
compute.googleapis.com)
A failed sub-scan names the real Google reason instead of axios's Request failed with status code 403: API not enabled, a specific missing permission, or the token belonging to a different identity than the service account you granted.
What is discovered
- Secret Manager: name, expiration (from enabled versions), creation/update times. Only enabled versions are checked. Metadata only; no secret values are retrieved.
- Certificate Manager: name, expiration, domains / SANs, managed vs self-managed, managed state. Location is always
gcp:<project>/locations/global/certificates/<name>. Regional Certificate Manager locations are not enumerated. - Compute Engine SSL certificates: name, expiration, domains / SANs, managed vs self-managed, managed status. A certificate with the same name in two scopes (for example
globalandregions/us-central1) is imported as two distinct tokens, with locationsgcp:<project>/global/sslCertificates/<name>andgcp:<project>/regions/<region>/sslCertificates/<name>.
Metadata only. No secret values, private keys, or certificate private keys are retrieved.
If you store a TLS certificate as a Secret Manager secret, it is still picked up by the Secrets checkbox like any other secret. Certificates issued through Certificate Manager or attached as Compute Engine sslCertificates are only found when Certificates is ticked.
Failed or incomplete scans
Each checkbox can succeed, fail, or come back incomplete on its own. The scan summary labels the rows Secrets, Certificate Manager, and Compute Engine SSL certificates, and a failed row shows a Failed badge plus the formatted Google error.
A certificate kind is reported incomplete (never complete-and-empty) when:
- that API returned an error,
- the scan's shared item budget cut the listing short,
- or Compute Engine's aggregated list could not reach one or more regions.
Obsolete-token cleanup only runs against kinds the scan reported fully complete, so a truncated or partly-errored certificate pass cannot delete real certificates it never actually checked.
GCP does not support auto-sync on self-hosted TokenTimer Core. Each scan is a one-time, manual action; credentials are used once and never stored. TokenTimer Enterprise adds scheduled auto-sync for this provider (secrets and certificates, using the same checkboxes) under a per-provider license entitlement; see Enterprise auto-sync.