Mastering GCP Identity: Why You Must Restrict Service Account Creation

Overview

In Google Cloud Platform (GCP), service accounts are the primary mechanism for applications and services to authenticate and access resources. While essential for automation, their uncontrolled creation leads to "identity sprawl"—a proliferation of non-human identities that are difficult to track, manage, and secure. This sprawl significantly increases the attack surface and creates hidden operational risks.

The core problem is that decentralized, ad-hoc creation of service accounts often bypasses security oversight. Developers, aiming for speed, might create accounts with overly broad permissions and long-lived keys, which then become forgotten liabilities.

A mature FinOps and security practice addresses this by shifting from a permissive model to a governed one. By implementing technical guardrails to prevent on-demand service account creation, organizations can enforce a centralized, auditable process for managing the lifecycle of every non-human identity in their GCP environment. This article explains how to implement this crucial control and why it’s a foundational element of cloud governance.

Why It Matters for FinOps

Restricting service account creation is not just a security task; it’s a critical FinOps discipline with direct business impact. Unmanaged identities introduce significant financial, operational, and compliance risks that can undermine the value of your cloud investment.

Failure to control identity creation exposes the organization to cryptojacking, where compromised service accounts are used to mine cryptocurrency, leading to massive, unexpected cloud bills. From a compliance standpoint, an inability to account for every identity in your environment is a common cause for failing SOC 2 or PCI DSS audits, which can delay sales cycles and damage customer trust.

Operationally, identity sprawl creates a drag on engineering teams. Auditing becomes nearly impossible, the principle of least privilege is eroded, and security teams are left trying to clean up a complex web of abandoned credentials. Enforcing a centralized creation process establishes clear ownership and purpose for every identity, streamlining operations and reducing security overhead.

What Counts as “Idle” in This Article

While this article focuses on preventing uncontrolled creation, the outcome is a reduction in waste, specifically from "unmanaged" or "orphaned" identities. These accounts are a form of financial and security waste because they represent unmonitored risk without delivering business value.

In this context, an unmanaged identity is any service account that exhibits signals of being idle or abandoned:

• It lacks a clear, documented owner or business purpose.
• It was created outside of an approved, automated provisioning workflow.
• It has overly broad permissions (e.g., Project Owner or Editor) that are not justified by its function.
• Its keys have not been rotated according to policy, or it has not been used for an extended period.

Identifying and preventing the creation of these accounts is key to maintaining a clean, secure, and cost-efficient GCP environment.

Common Scenarios

Scenario 1

A developer needs to access a Cloud Storage bucket for a new feature. To simplify troubleshooting, they create a new service account named temp-admin-sa, grant it Owner permissions, and download the key to their local machine. With a preventative policy in place, this action would be blocked, forcing the developer to follow a formal process that ensures least privilege and proper documentation.

Scenario 2

An organization’s infrastructure-as-code (IaC) pipeline, such as one using Terraform, is configured with a highly privileged identity that creates other service accounts as part of its deployment process. Enforcing a global restriction would cause these pipelines to fail. The solution is to create a specific, documented exception for the IaC project, ensuring that automation can proceed within a controlled and audited scope.

Scenario 3

A team using Google Kubernetes Engine (GKE) needs to configure Workload Identity, which maps Kubernetes Service Accounts to GCP Service Accounts. If a global creation block is in effect, administrators cannot configure new workloads. The best practice is to delegate GSA creation to a governed process, even for GKE, ensuring that all identities, regardless of their use case, are provisioned through a centralized and secure mechanism.

Risks and Trade-offs

Implementing a strict policy against service account creation introduces intentional friction. The primary trade-off is between enhanced security control and developer velocity. Teams accustomed to creating identities on demand will face blockers, which can slow down development and testing cycles if a viable alternative is not provided.

There is also a significant risk of breaking existing automated workflows. Legacy deployment scripts or third-party tools that assume the ability to create service accounts will fail abruptly. This "don’t break prod" concern requires a careful, phased rollout, starting with an audit of current creation patterns and communicating changes clearly to all engineering teams. The goal is to introduce governance without halting business-critical operations.

Recommended Guardrails

A successful implementation relies on establishing clear, proactive governance policies rather than just flipping a switch.

• Centralized Provisioning: Create a formal, automated "vending machine" process for requesting and approving new service accounts. This ensures every identity has a documented owner, purpose, and is granted least-privilege permissions from the start.
• Tagging and Exceptions: Use GCP’s resource tags to manage policy exceptions. Designate a specific project or folder for identity management and exempt it from the restriction, allowing your automated provisioning pipeline to operate.
• Ownership and Lifecycle: Mandate that every service account be associated with a team or individual owner. Implement automated processes for periodic review, key rotation, and de-provisioning of unused accounts.
• Budgets and Alerts: Set up alerts in Cloud Monitoring to detect denied creation attempts. This can indicate a misconfigured automation or a user attempting to bypass the established process, providing valuable feedback for refining your governance strategy.

Provider Notes

GCP

The primary tool for enforcing this control in Google Cloud is the Organization Policy Service. This service allows you to set broad constraints on how resources can be used across your entire organization.

The specific constraint to use is iam.disableServiceAccountCreation. By setting this boolean constraint to True at the organization level, you block the iam.serviceAccounts.create permission for all users and services. You can then configure the policy to exempt specific projects or folders where creation is permitted through your automated pipeline. All creation events, whether successful or denied by policy, can be monitored using Cloud Audit Logs.

Binadox Operational Playbook

Binadox Insight: Proactively managing identity creation is a hallmark of a mature FinOps practice. It transforms security from a reactive cleanup task into a proactive governance function, directly reducing financial risk from compromised credentials and eliminating the operational waste of unmanaged resources.

Binadox Checklist:

• Audit Cloud Audit Logs to identify who is creating service accounts and where.
• Inventory and remove existing orphaned or overly-privileged service accounts.
• Design a centralized "identity factory" project and exempt it from the organization policy.
• Build an automated, self-service workflow for developers to request new service accounts.
• Implement the iam.disableServiceAccountCreation organization policy in a dry-run mode before full enforcement.
• Configure alerts to monitor for denied creation attempts, which signal process gaps.

Binadox KPIs to Track:

• Reduction in the number of active service accounts with Owner or Editor roles.
• Average time-to-provision for a new service account request via the automated pipeline.
• Number of policy violation alerts triggered per week.
• Percentage of service accounts with a clearly defined and tagged owner.

Binadox Common Pitfalls:

• Enforcing the policy without providing a fast, developer-friendly alternative for provisioning.
• Creating an exception list that is too broad, undermining the purpose of the control.
• Failing to audit and clean up existing unmanaged service accounts before locking down creation.
• Neglecting to monitor policy denial alerts, missing key insights into broken workflows or process gaps.

Conclusion

Restricting ad-hoc service account creation is a powerful and necessary step for any organization serious about security and financial governance in GCP. By leveraging Organization Policies, you can move away from a chaotic, high-risk environment and toward a "secure by design" model where every identity is known, managed, and purposeful.

While this change requires upfront investment in process and automation, the benefits are clear: a drastically reduced attack surface, stronger compliance posture, and a more efficient, predictable cloud environment. Start by auditing your current state, then build the guardrails to ensure your GCP identity perimeter remains secure and cost-effective as you scale.