Hello? Whose service account keys are these?

Hello? Whose Service Account Keys Are These?

Speakers: Lee Livsey, Director, Reversec

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=txftiCD-Ryk

Overview

Lee Livsey, a security consultant at Reverse Sec specializing in GCP assessments, presented a focused examination of long-lived service account keys in Google Cloud Platform and why they represent a significant but underappreciated security risk. The talk centers on a real-world case study where Livsey discovered a GCP service account private key—with Storage Admin privileges and no expiration date—being transmitted in plaintext within HTTP responses of a Google-managed service called Contact Center AI (CCAI). The finding illustrates that even Google's own partners and managed service developers make fundamental mistakes with service account key management, and that GCP's default behavior of creating non-expiring keys, combined with an organization constraint that is routinely disabled, means long-lived credentials remain pervasive across GCP environments. The talk provides practical guidance for identifying, mitigating, and eliminating these keys through federated identity and workload identity federation.

Background

▶ Watch: Observes the AWS-to-GCP migration trend and why long-lived GCP credentials do... (1:30)

As organizations increasingly adopt multi-cloud strategies, many security professionals are transitioning from AWS-centric environments to GCP. Livsey observed that while GCP handles human identity well by default—typically using Google Workspace as a directory provider with MFA, or federated through Entra ID—the picture for service accounts is significantly worse. GCP service accounts come in two varieties: Google-managed service agents (which have been thoroughly researched by security researchers like Catrax) and user-managed service accounts that organizations create within their projects for machine-to-machine authentication. User-managed service account keys are RSA private keys that, by default, have no expiration date. Google intentionally designed this behavior to prevent production workload disruptions, but the result is a security posture that leans too far toward usability at the expense of security. Additionally, while Google has enabled an organization constraint (iam.disableServiceAccountKeyCreation) by default on new organizations to prevent key creation, Livsey demonstrated through a show of hands that many practitioners in the audience had disabled this constraint.

Key Findings

▶ Watch: Introduction to the Contact Center AI case study — a Google managed service w... (6:30)

The headline finding is the discovery of a full GCP service account private key exposed in the HTTP responses of a Google-managed service—Contact Center AI (CCAI), formerly known as the Contact Center Artificial Intelligence Platform. The key was assigned the Storage Admin role, had no configured expiration (defaulting to never-expire), and was transmitted to every authenticated user of the web application. This means any contact center worker using the portal could extract the key through browser developer tools and authenticate directly to the client's GCP environment with elevated storage permissions.

The root cause analysis suggests the vulnerability originated from the service's architecture. The partner-managed web application needed to push ETL data from their own project to the client's GCP project. Rather than using Workload Identity Federation for cross-project communication, the development team embedded a service account key in the web application—a mistake that Livsey noted parallels the risks previously documented with vendors requesting AWS IAM users for cross-account access.

Beyond the specific finding, Livsey highlighted several systemic issues with GCP's service account key management. The console provides no option to manually configure key lifetime during creation—keys are created with a hardcoded end-of-time expiration. Google's documentation explicitly states this is intentional, citing concerns about service disruption if keys expire on production workloads. While Google-managed service agent keys expire after approximately one year, user-managed keys do not benefit from the same rotation, creating an asymmetry in the security model. The organization constraint to disable key creation exists but is not yet a viable guardrail in practice, as many organizations disable it to accommodate legitimate use cases.

Technical Deep Dive

▶ Watch: Root cause analysis: partner team used service account key for cross-project ... (10:00)

GCP service account keys are standard RSA private keys enclosed in -----BEGIN PRIVATE KEY----- and -----END PRIVATE KEY----- markers. When generated through the GCP console, no lifetime configuration is available—the only option is to create a key with default (permanent) expiration. There is an alternative path: uploading a self-generated key allows specifying a custom expiration date, but this requires a more complex workflow outside the standard gcloud CLI commands and is not widely known or used.

The Contact Center AI finding was discovered during a security assessment where Livsey's typical approach of reading documentation and spinning up test environments was not possible due to quota restrictions—the service required Google partner access to deploy. Working solely through the web portal provided to the client, Livsey identified the service account key in HTTP request/response traffic. Using JQ and regex extraction, the full private key was recoverable from the API responses. The key was assigned Storage Admin on the client's project, providing broad read/write/delete access to all Cloud Storage resources.

For detection, Livsey provided a practical approach using gcloud CLI: enumerate service accounts per project, list their keys, and grep for keys with expiration dates far in the future (e.g., 9999 or 9998 for never-expiring keys, or specific year thresholds like 2027 for keys expiring beyond an acceptable window). The console also provides visual enumeration of keys by project.

The recommended solution architecture centers on Workload Identity Federation, which eliminates the need for service account keys by allowing external workloads to authenticate using federated tokens. For the CCAI case specifically, the data pipeline should route through the partner's own project first—leveraging the authenticated web session—before using a backend service account (without key export) to push data cross-project. For scenarios genuinely requiring long-lived credentials (such as IoT devices with hardware constraints), certificate-based access with a private CA provides an alternative that avoids key distribution.

Google's disclosure process for this finding was efficient—the vulnerability was reported, triaged quickly without pushback, and fixed by August. Livsey highlighted this as a positive example compared to difficulties other researchers have experienced with cloud provider disclosure processes.

Demo / Proof of Concept

▶ Watch: Google documentation confirms non-expiring keys are intentional — prioritizin... (12:00)

Livsey walked through the discovery process showing screenshots of the web application's HTTP traffic containing the service account key, the JQ/regex extraction of the full private key from the response payload, and the resulting authentication to the client's GCP environment. No live exploitation was performed, but the screenshots provided clear evidence of the key exposure and its Storage Admin role assignment.

Defensive Implications

▶ Watch: Practical detection: bash script using gcloud CLI to enumerate and grep for l... (15:00)

Organizations using GCP should immediately audit their environments for long-lived service account keys using gcloud CLI enumeration scripts. Establish a maximum acceptable key age and flag or rotate keys exceeding that threshold. Push vendors and partners to support Workload Identity Federation rather than requiring service account keys for cross-project or cross-organization access. Evaluate the iam.disableServiceAccountKeyCreation organization constraint carefully—if it must be disabled, implement compensating controls such as automated key rotation and monitoring. For managed services and partner-provided applications, specifically audit how they authenticate to your GCP environment and whether they transmit credential material in web application traffic. Consider using the constraints/iam.serviceAccountKeyExpiryHours organization policy to set maximum lifetimes for newly created keys. The community should collectively advocate for Google to improve default key expiration behavior and provide better console tooling for key lifecycle management.

Key Takeaways

• GCP service account keys never expire by default, and there is no console option to set a custom lifetime during creation—this is an intentional Google design decision favoring availability over security
• Even Google's managed service partners make mistakes with service account keys, as demonstrated by a Contact Center AI finding where a Storage Admin key was exposed in HTTP responses
• The organization constraint to disable key creation exists but is routinely disabled in practice, making it an ineffective guardrail in its current form
• Workload Identity Federation should replace service account keys wherever possible for cross-project and cross-organization authentication
• Long-lived credential risks in GCP parallel AWS — the same problems with IAM users and access keys exist with GCP service account keys, but receive less community attention
• Audit vendor integrations for credential material in web application traffic, especially for managed services that bridge partner and client GCP projects

About the Speaker(s)

Lee Livsey is a Director and security consultant at Reverse Sec, a UK-based security firm focused on offensive security assessments. He specializes in GCP security assessments and has extensive experience across AWS and Azure environments. His work focuses on helping clients improve their security posture through vulnerability identification and assessment of cloud-native services.