Enforcing GCP Service Account Key Governance

Overview

In Google Cloud Platform (GCP), Service Accounts are non-human identities that applications and services use to authenticate with Google APIs. Securing these accounts is a cornerstone of cloud governance, as they often hold powerful permissions to access sensitive data and critical infrastructure. A significant security vulnerability arises from how their credentials—service account keys—are managed.

While GCP can generate and manage keys within its secure environment, it also provides a feature allowing users to generate keys externally and upload the public portion. This practice, often called "Bring Your Own Key" (BYOK), creates a dangerous blind spot. Enforcing a policy to disable service account key uploads is a critical preventative measure that closes this security gap, ensuring all credentials originate from a trusted, auditable source.

Why It Matters for FinOps

The implications of mismanaged service account keys extend beyond security and directly impact financial operations. A compromised key, especially one generated in an unmonitored environment like a developer’s workstation, is a prime target for abuse. Attackers frequently use stolen credentials to provision expensive resources for activities like cryptocurrency mining, leading to significant and unexpected cost overruns that can inflate cloud bills by thousands of dollars.

Beyond direct financial waste, a lack of control over key creation introduces operational drag. Incident response efforts to track down the source of a breach and remediate the damage are costly and time-consuming. Furthermore, failing to enforce this fundamental security control can result in failed compliance audits for frameworks like CIS, PCI DSS, and SOC 2, putting business contracts and regulatory standing at risk. Strong key governance is not just a security task; it is an essential component of a mature FinOps practice.

What Counts as “Idle” in This Article

While this article focuses on a security policy rather than idle resources, the core issue is unmanaged and untraceable credentials. For clarity, it’s important to understand the two primary types of service account keys in GCP:

1. GCP-Managed Keys: These are created, managed, and automatically rotated by Google. Users cannot view or download the private portion, making them the most secure option for resources running within GCP.
2. User-Managed Keys: These are created by users to allow applications outside of GCP to authenticate. Within this category, a key can be created (GCP generates the key pair and provides the private key once) or uploaded (a user generates the key pair externally and uploads the public key to GCP).

This article is focused on prohibiting the uploaded key scenario. These keys have an unknown origin, lack an auditable creation trail within GCP, and represent the highest level of risk.

Common Scenarios

Scenario 1

A CI/CD pipeline, such as Jenkins or GitHub Actions, needs to deploy applications to a GKE cluster. An engineer might generate a key pair on their local machine, upload the public key to a service account, and store the private key as a secret in the CI/CD tool. This creates a long-lived, static credential whose private half has existed outside of GCP’s secure boundary.

Scenario 2

An on-premises application needs to read data from a Cloud Storage bucket. To establish a quick connection, a developer generates a key pair on the on-prem server, uploads the public key, and embeds the private key in a local configuration file. This key is now exposed on the server’s filesystem and is unlikely to be rotated according to cloud best practices.

Scenario 3

A third-party SaaS provider requires access to a company’s BigQuery dataset for analytics. The vendor requests a service account key to configure their platform. Allowing the vendor to provide their own public key, or providing them with a downloaded key, externalizes credential management and creates a dependency on the vendor’s security practices.

Risks and Trade-offs

Allowing key uploads introduces severe risks. The primary risk is the loss of provenance; there is no GCP audit trail for when or how the private key was generated. It could have been created on a compromised machine or accidentally committed to a public code repository before ever being associated with GCP. This undermines non-repudiation, making it impossible to trace malicious activity back to a specific origin. It also encourages poor security hygiene, as these keys are rarely rotated and often become permanent, static secrets.

The main trade-off of blocking key uploads is that it may disrupt legacy applications that were built using this method. Before enforcing this guardrail, organizations must perform a thorough audit to identify existing uploaded keys and plan a migration strategy. While this requires an upfront investment, the long-term security and governance benefits far outweigh the risk of leaving this attack vector open.

Recommended Guardrails

A robust governance strategy is essential for managing service account keys effectively. The most effective guardrail is implementing a GCP Organization Policy to programmatically block key uploads across your entire cloud environment.

Complementary guardrails include:

• Tagging and Ownership: Enforce a strict tagging policy for all service accounts to ensure clear ownership and accountability.
• Approval Workflows: Establish a process where the creation of any user-managed key requires justification and management approval.
• Budget Alerts: Configure billing alerts tied to specific projects or labels to quickly detect anomalous spend that could indicate a compromised key.
• Continuous Monitoring: Use automated tools to monitor for the creation of new user-managed keys and alert the security team.

Provider Notes

GCP

Google Cloud Platform provides the tools needed to enforce this control directly through its governance framework. The key mechanism is the Organization Policy Service, which allows administrators to set constraints on resource configurations.

To prevent key uploads, you can enforce the iam.disableServiceAccountKeyUpload constraint. This policy, when applied at the organization or folder level, prevents any IAM principal from uploading external public keys to service accounts within that scope. All key creation and management events are logged in Cloud Audit Logs, providing a clear record of activity. For modern applications, GCP recommends avoiding user-managed keys altogether in favor of Workload Identity Federation, which allows external workloads to impersonate a service account without needing a static key.

Binadox Operational Playbook

Binadox Insight: Disabling service account key uploads is a powerful forcing function. It pushes engineering teams to abandon risky, outdated authentication patterns and adopt more secure, modern methods like Workload Identity Federation, fundamentally reducing the organization’s attack surface.

Binadox Checklist:

• Audit your GCP environment for any existing user-managed service account keys.
• Identify the owners of these keys and the applications that use them.
• Develop a migration plan to replace uploaded keys with federated identities or GCP-created keys.
• Communicate the upcoming policy change to all development and operations teams.
• Enforce the iam.disableServiceAccountKeyUpload Organization Policy, starting with non-production environments.
• Document a clear exception process using conditional policies and resource tags for any critical legacy use cases.

Binadox KPIs to Track:

• Total number of user-managed service account keys (trending down).
• Percentage of projects where the key upload policy is enforced.
• Time-to-remediate for any new user-managed keys that are created.
• Adoption rate of Workload Identity Federation for external services.

Binadox Common Pitfalls:

• Enforcing the policy without first auditing for existing keys, causing production outages.
• Failing to provide developers with clear guidance and training on secure alternatives.
• Creating a broad, permanent exception process that undermines the policy’s effectiveness.
• Neglecting to monitor for policy violations or new key creation events after initial enforcement.

Conclusion

Securing service account identities is non-negotiable for any organization operating on GCP. The ability to upload externally generated keys creates an unacceptable security risk with direct financial consequences. By implementing the guardrails discussed in this article, you can close this loophole and strengthen your governance posture.

The next step is to begin the discovery process within your own environment. Audit your existing keys, communicate with your teams, and enforce the Organization Policy to disable key uploads. This action will not only enhance your security but also drive a broader shift toward more mature and cost-effective cloud identity management practices.