oleria

Quick Summary: GCP service account keys created outside of automated workflows go untracked — no rotation schedule, no named owner, no expiry. Oleria, an AI-native identity security & governance platform, finds every untracked GCP service account key across your environment and flags them for rotation or elimination before one is exploited.

Outcome

GCP JSON keys are downloadable, long-lived private keys that work until someone manually deletes them. Most enterprises have hundreds they've never inventoried - and workload identity federation migration, the only real fix, has the lowest completion rate of any high-value posture improvement because nobody knows which keys are migration candidates.

The reality

GCP service accounts authenticate workloads to Google APIs. JSON keys are the legacy mechanism: a downloadable file containing a private key with the service account's full effective scope. Once leaked, the key works until manually deleted. The U.S. Treasury 2024 breach had API-key parallels in the public framing; GCP's analog risk is the JSON key.

Google's own documentation now leads with workload identity federation as the recommended path. The migration is real work: replacing static keys with OIDC trust between Kubernetes, AWS, Azure, or other federated workload sources. It's also the highest-value posture improvement available - and the lowest-completion. The reason: identifying which keys are migration candidates requires usage analysis nobody runs. The work hasn't gotten done at scale because the inventory doesn't exist.

What you get with Oleria

Oleria's GCP Service Account Key Discovery and Elimination capability gives you the complete cross-project picture your security program has been missing — every JSON key, every service account, every federation gap, in a single queryable inventory.

Complete cross-project visibility - no project left unscanned.

Complete cross-project visibility - no project left unscanned. Service accounts across every GCP project with read access, including keys, federation status, and IAM bindings, in one inventory.

JSON key age and last-used - the data you need to prioritize rotation.

Per key: created date, last-authenticated timestamp, and age, all sortable. Builds the stale-key cleanup queue automatically.

Effective IAM scope across the org hierarchy.

What roles each service account holds across projects, folders, and organization level - not just bindings at one level, so you see the real blast radius.

What good looks like

Before: No one knows how many JSON keys exist org-wide or which projects have stale keys with admin scope. After: Full cross-project inventory, sortable by key age and last-used, with a named migration queue.
Workload identity federation migration tracked as a measurable program - candidates identified, progress visible, completion rate measurable quarter over quarter.
Keys with admin scope reviewed quarterly with a named reviewer - no anonymous, unowned credentials with org-level blast radius.
Zero "key in code" surprises - the inventory reflects what is actually in use, not what was provisioned years ago.

‍

Frequently Asked Questions

Do you cover both human-created and Google-managed service accounts?

Yes. Default service accounts (created by Google for products like Compute Engine) and user-created service accounts both surface, with their distinct lifecycle treatment.

What about service account impersonation chains?

Impersonation IAM (serviceAccountTokenCreator) shows up as scope. Three-hop impersonation chains traced.

How does this differ from using gcloud or the Google Cloud Console directly?

gcloud and the Console show you keys per project, one project at a time, with no last-used data surfaced in the UI. Oleria aggregates org-wide, surfaces last-authenticated timestamps, and builds the stale-key queue automatically.

How are keys discovered when they were created via Terraform or other IaC automation?

Discovery reads from GCP APIs, not from IaC state files, so keys created by Terraform, Pulumi, or any automation appear regardless of whether the IaC repo is accessible.

Does this work across multiple GCP projects and organizations?

Yes. A single org-level read grant covers all projects under that organization.

How current is the inventory, and does it map to compliance frameworks?

Inventory refresh runs on a scheduled pull cycle. For compliance, the stale-key and over-scoped-key findings map directly to CIS Google Cloud Benchmark controls (sections 1.4, 1.7) and NIST SP 800-53 AC-2 and IA-5.

Find every untracked GCP service account key and eliminate it before it shows up in a breach report