Overview
Google Cloud Platform (GCP) is designed for rapid deployment, but this convenience can introduce significant security risks. One of the most critical examples is the "default" Virtual Private Cloud (VPC) network, which GCP automatically creates in every new project. While intended to help developers get started quickly, this network is configured with overly permissive firewall rules and problematic IP address ranges that are unsuitable for any production environment.
This default configuration directly contradicts the principle of "secure by design." It exposes management ports like SSH and RDP to the entire internet and allows unrestricted internal traffic between all resources within the network. For any organization serious about cloud security and cost governance, addressing this default setting is not just a best practice—it is a foundational requirement for building a secure and scalable GCP environment. Proactively disabling the creation of this network is a key step in establishing strong security and FinOps guardrails.
Why It Matters for FinOps
Allowing the default network to persist creates direct business and financial risks. From a FinOps perspective, it represents a significant source of future waste and operational drag. The insecure firewall rules dramatically increase the likelihood of a security breach, which can lead to catastrophic financial losses, reputational damage, and regulatory fines.
Architecturally, every default network uses the same overlapping IP address ranges. This makes it impossible to connect projects using VPC Peering or Cloud VPN, a common requirement as an organization scales. When cross-project connectivity becomes necessary, teams are forced into expensive and time-consuming network migration projects. This "re-IPing" process halts new feature development, consumes valuable engineering resources, and introduces risks of service disruption—all of which could have been avoided with a simple governance policy from the start. Furthermore, its presence is an immediate red flag in compliance audits for standards like CIS, PCI-DSS, and SOC 2, leading to costly remediation cycles.
What Counts as “Idle” in This Article
While not "idle" in the traditional sense of an unused virtual machine, the Google Cloud default network represents a form of architectural waste. It’s an unmanaged, insecure resource created without explicit business intent or proper governance. For the purposes of this article, we consider any cloud asset or configuration that exists by default rather than by design to be a source of risk and inefficiency.
The default network is a prime example: it is provisioned automatically, carries significant security baggage, and lacks the oversight required for enterprise workloads. The primary signals of this problematic configuration are its default-open firewall rules (e.g., allowing SSH from 0.0.0.0/0) and its use of predictable, non-routable IP ranges that create future technical debt.
Common Scenarios
Scenario 1
An automated "project factory" pipeline, built with Terraform or another IaC tool, provisions new GCP projects for development teams. If the automation script omits the flag to disable default network creation, every new project is silently provisioned with this insecure network, creating widespread, systemic risk across the organization.
Scenario 2
A data science team uses Vertex AI to quickly spin up Notebook instances for a proof-of-concept. Without a governing policy, these instances are often deployed into the default network. This can inadvertently expose sensitive data models or intellectual property to the internet via the network’s permissive SSH and RDP rules.
Scenario 3
A developer creates a "sandbox" project for a quick test. This project, using the default network, eventually becomes a critical, forgotten-about dependency for a production application. The insecure network configuration is carried into production, creating a hidden but significant vulnerability in the company’s infrastructure.
Risks and Trade-offs
The primary risk of inaction is a security breach. The default firewall rules are an open invitation for automated scanners looking for exposed management ports, making instances vulnerable to brute-force attacks and lateral movement if compromised.
The main trade-off in remediating existing projects is operational disruption. Simply deleting the default network while resources are running within it will cause an immediate and complete outage for those services. A careful, planned migration to a new, custom-designed VPC is required. This involves potential downtime and requires engineering effort, which must be weighed against the persistent security risk of leaving the network in place. For new projects, the only trade-off is a minor initial setup step where developers must consciously define their network needs, which is a desirable outcome for security and governance.
Recommended Guardrails
A robust governance strategy is the best defense against the risks of the default network. This starts with implementing preventative controls and clear policies.
Establish an organization-wide policy that programmatically prohibits the creation of the default network in all new projects. This is the most effective guardrail. Supplement this with a strong tagging and ownership policy, ensuring every custom network and its associated resources are assigned to a specific team or cost center. Implement automated security scans to continuously audit existing projects for any lingering default networks that predate the policy. For regulated environments, integrate this check into your compliance reporting dashboards to ensure ongoing adherence.
Provider Notes
GCP
Google Cloud provides a powerful mechanism to enforce this control at scale through its Organization Policy Service. The specific constraint, constraints/compute.skipDefaultNetworkCreation, allows administrators to prevent any new project from being created with the insecure default VPC network. When this policy is enforced, developers are required to create a "custom mode" VPC, giving them full control over subnets, IP ranges, and firewall rules. This ensures that network architecture is an intentional design decision, not an insecure afterthought. The use of custom VPCs also avoids the IP address conflicts that prevent VPC Network Peering between projects that use the default network.
Binadox Operational Playbook
Binadox Insight: Prohibiting the GCP default network is one of the highest-impact security controls you can implement. It acts as a powerful FinOps lever, preventing costly future migrations and reducing the attack surface, thereby translating a simple policy change into significant risk reduction and operational savings.
Binadox Checklist:
- Audit your entire GCP organization to identify all existing projects where the "default" network is present.
- Enforce the
compute.skipDefaultNetworkCreationconstraint at the root of your organization hierarchy to prevent future occurrences. - Develop a standardized migration plan for applications currently running in a default network.
- Create and communicate a set of pre-approved, custom VPC templates for common use cases.
- Update your internal documentation and developer onboarding materials to reflect the new networking policy.
- Implement continuous monitoring to detect any policy overrides or new, non-compliant projects.
Binadox KPIs to Track:
- Percentage of projects compliant with the no-default-network policy.
- Number of active default networks discovered per month.
- Mean Time to Remediate (MTTR) for migrating workloads out of a default network.
- Reduction in security findings related to overly permissive firewall rules.
Binadox Common Pitfalls:
- Deleting a default network without first migrating all active resources, causing an outage.
- Failing to communicate the policy change, leading to confusion and stalled projects for development teams.
- Overlooking legacy or "shadow IT" projects that are not subject to standard audits.
- Not providing developers with secure, easy-to-use custom network templates as an alternative.
Conclusion
The GCP default network is a liability disguised as a convenience. Its inherent security flaws and architectural limitations make it unsuitable for any organization committed to secure and efficient cloud operations.
The path forward is clear: enforce a preventative guardrail using GCP’s Organization Policy to block its creation in all new projects. For existing infrastructure, conduct a thorough audit and execute a planned migration to secure, custom-designed networks. By taking these decisive steps, you can eliminate a major category of risk, strengthen your compliance posture, and ensure your cloud architecture is built on a foundation of security and scalability.
7-day free trial