alphaspirit - Fotolia
Explore Google XPN for virtual private cloud networks
Isolated networks strengthen cloud security, but sharing data can become a challenge. Learn how Google XPN enables multiple users or departments to share one virtual private cloud.
Network segmentation has been a standard IT security practice for decades. For many organizations, this makes the ability to create virtual private cloud subnets within a particular service, such as Amazon Web Services or Google Cloud Platform, a powerful feature.
Amazon Web Services (AWS) was the first to offer virtual private clouds (VPCs) as a way to partition a cloud platform and to securely connect to enterprise data centers via a virtual private network (VPN). But alternatives, such as Google's Shared VPC Network (XPN), currently in beta, have emerged.
One challenge with AWS is that its VPCs are limited to a single account, which becomes an issue when an entire enterprise, rather than just a specific department, adopts public cloud. When users require isolated workloads, AWS recommends they create multiple accounts for separate VPCs, but this creates issues when teams need to share code or data.
Google XPN, on the other hand, specifically targets these types of scenarios.
When to consider Google XPN
Google XPN is useful when different groups develop and manage two or more application modules or services that must interact within Google Cloud Platform (GCP). A more common scenario is hybrid cloud, where services on GCP use resources in a private data center. Here, a separate group owns and manages each cloud application or service, but those services need to communicate over a shared VPC with a VPN gateway from Google Cloud to the data center.
XPN allows each project to run independently, with separate control for the network configuration and security policy for the VPC, VPN gateway and internal networks. An organization can set up multiple Google XPNs within the same VPC with policies that control their access to both on-premises resources and each other.
Technical concepts
Google XPN enables multi-tenant sharing of a virtual private cloud that can connect GCP resources via a private network. This network can span multiple GCP regions.
To achieve this segmentation, Google XPN implements standard IP Network Address Translation spaces for different projects within an organization-wide VPC. As part of a VPC, Google XPNs inherit security features and control network traffic through firewall rules. Cloud admins can then create VPNs and configure firewall rules that apply to the entire VPC, and also establish access controls between projects on different subnets.
Google XPN: Key terms to know
- Organization: The owner of all projects and resources in a GCP deployment that's also typically responsible for billing, overall security policy, and identity and access management.
- Billing: Traffic billing across projects in a shared VPC, whether using XPC or not, is consolidated, as if it were a single project.
- Host project: The umbrella project within a Google Cloud organization that contains a shared VPC and one or more service projects.
- Service project: A project dedicated to a department, development team or other enterprise segment that manages dedicated GCP instances and shares a VPC.
- Stand-alone project: A project within a shared VPC that is not part of an XPN.
- Administrators: A three-level hierarchy of those responsible for managing an organization, XPN and individual service project.
When users keep all projects within a VPC, they can enforce consistent policies and provide a virtual sandbox for each app development team. With XPN, the shared VPC acts as an umbrella for a host project under which separate project namespaces are carved out. For example, an organization has three projects in a single VPC, each with its own subnet. One project needs to be isolated, but the two other projects require network connectivity to share code for integration testing. In this scenario, the stand-alone project remains on an isolated subnet, while the other two projects are connected under a Google XPN host project.
Limitations and challenges
Google XPNs and associated service projects must all belong to the same Google organization. They also face the following restrictions and limitations:
- An organization can have multiple XPNs; however, a service project can only belong to a single XPN.
- Admins can associate existing projects to a new Google XPN, but can't migrate previously instantiated VM instances in the service network; they must stop and recreate them in the XPN.
- A shared virtual private cloud can only have up to 7,000 instances across all projects in the network, and no more than 50 forwarding rules for internal load balancing.
- Service projects share the total resource quotas from a pool set for the entire VPC. For example, a host or service project can't have more load balancer forwarding rules than are allowed by the overall quota.
- While XPN is in beta, it's limited to 100 host projects per cloud organization and 100 service projects attached to a particular host project. Furthermore, external load balancing across projects isn't supported, meaning the load balancer must exist within the same host project as the back ends.
Another challenge is that Google XPN security is easy to misconfigure. For example, although it checks security policies to make sure users have the right to create an instance in a particular subnet, these controls don't apply when putting instance templates into a service project. As a result, users could end up in a situation where they have permission to create a template, but not to instantiate the resources specified in the template.
