Network security for distributed applications in Cross-Cloud Network

This document is part of a design guide series for Cross-Cloud Network.This part explores the network security layer.

The series consists of the following parts:

Security surfaces

When you design the security layer for the Cross-Cloud Network,you must consider the following security surfaces:

  • Workload security
  • Domain perimeter security

Workload security controls the communication between workloads across and withinthe Virtual Private Cloud (VPC). Workload security uses security enforcementpoints that are close to the workloads in the architecture. Whenever possible,Cross-Cloud Network provides workload security by usingCloud Next Generation Firewall from Google Cloud.

Perimeter security is required at all network boundaries. Because the perimeterusually interconnects networks that are managed by different organizations,tighter security controls are often required. You must ensure that the followingcommunications across networks are secured:

  • Communications across VPCs
  • Communications across hybrid connections to other cloud providers oron-premises data centers
  • Communications to the internet

The ability to insert third-party network virtual appliances (NVAs) within theGoogle Cloud environment is critical to address the requirements forperimeter security across hybrid connections.

Workload security in cloud

Usefirewall policies inGoogle Cloud to secure workloads and provide stateful firewallcapabilities that are horizontally scalable and applied to each VM instance. Thedistributed nature of Google Cloud firewalls helps you implement securitypolicies for network micro-segmentation without negatively impacting theperformance of your workloads.

UseHierarchical firewall policies toimprove the manageability and enforce posture compliance for your firewallpolicies. Hierarchical firewall policies let you create and enforce a consistentfirewall policy across your organization. You can assignHierarchical firewall policies to the organization or to individual folders.In addition, Hierarchical firewall policies rules can delegate evaluation tolower-level policies (global or regional network firewall policies) with agoto_next action.

Lower-level rules cannot override a rule from a higher level in the resourcehierarchy. This rule structure lets organization-wide administrators managemandatory firewall rules in one place. Common use cases forHierarchical firewall policies include organization or multi-project bastion hostaccess, permitting centralized probing or health check systems, and enforcing avirtual network boundary across an organization or group of projects. Foradditional examples of usingHierarchical firewall policies, seeHierarchical firewall policiesexamples.

Useglobal andregional networkfirewall policies to define rules onan individual VPC-network basis, either for all regions of thenetwork (global) or a singleregion (regional).

To achieve more granular controls enforced at the virtual machine (VM) level, werecommend that you use Identity and Access Management (IAM)-governedtags at the organization or projectlevel. IAM-governed tags allows applying firewall rules based on the identity ofworkload host, as opposed to host IP address, and works acrossVPC Network Peering. Firewall rules deployed using tags can provide intra-subnetmicro-segmentation with policy coverage that automatically applies to workloadswherever they are deployed, independent of the network architecture.

In addition to stateful inspection capabilities and tag support,Cloud Next Generation Firewall also supports Threat Intelligence, FQDN, andgeolocation filtering.

We recommend that youmigrate from VPC firewall rules tofirewall policies.To assist with the migration, use themigrationtool,which creates a global network firewall policy and converts existingVPC firewall rules into the new policy.

Perimeter security in cloud

In a multicloud network environment, perimeter security is usuallyimplemented at each network. For example, the on-premises network has its ownset of perimeter firewalls, while each cloud network implements separateperimeter firewalls.

Because the Cross-Cloud Network is designed to be the hub for allcommunications, you can unify and centralize the perimeter security controls anddeploy a single set of perimeter firewalls in yourCross-Cloud Network. To deliver a built-in perimeter securitystack of choice, Cross-Cloud Network provides flexibleoptions for you to insert NVAs.

In the designs shown in the diagrams, you can deploy third-party NVAs in the transitVPC in the hub project.

NVAs can be deployed over a single network interface (single-NIC mode) or overmultiple network interfaces across multiple VPCs (multi-NICmode). For Cross-Cloud Network, we recommend a single-NICdeployment for NVAs, because this option lets you do the following:

  • Insert the NVAs with policy-based routes.
  • Avoid creating rigid topologies.
  • Deploy in a variety of inter-VPC topologies.
  • Enable autoscaling for the NVAs.
  • Scale to many VPCs over time, without required changes to theNVA interface deployment.

If your design requires multi-NIC, recommendations are detailed inMulti-NICNVA perimeter security.

To accomplish the traffic steering that's required for NVA deployment, thisguide recommends the selective enforcement of policy-based and static routesin the VPC routing tables. The policy-based routes are moreflexible than standard routes because policy-based routes match on both source and destinationinformation. These policy-based routes are also enforced only at specific placesin the cloud network topology. This granularity allows the definition of veryspecific traffic steering behavior for very specific connectivity flows.

In addition, this design enables the resiliency mechanisms required by theNVAs. NVAs are fronted by aninternal TCP/UDP loadbalancer to enable NVA redundancy, autoscalingfor elastic capacity, and flow symmetry to support stateful bi-directionaltraffic processing.

Single-NIC NVA perimeter security

In the design described inInter-VPC connectivity forcentralizedservices,the transit VPC acts as a hub to the spoke VPCsthat are connected by using VPC Network Peering and HA VPN.The transit VPC also enables connectivity between the externalnetworks and the spoke VPCs.

For the purpose of single-NIC NVA insertion, this design combines the followingtwo patterns:

  • Insert NVAs at a VPC Network Peering hub with external hybridconnections
  • Insert NVAs at an HA VPN VPC hub withexternal hybrid connections

The following diagram shows NVAs inserted at the hubs forVPC Network Peering and HA VPN:

NVAs inserted at the hubs for VPC Network Peering and HA VPN

The preceding diagram illustrates a combined pattern:

  • A transit VPC that hosts the Cloud Interconnect VLANattachments that provide hybrid or multicloud connectivity. This VPC alsocontains the single-NIC NVAs that monitor the hybrid connections.
  • Application VPCs connected to the transit VPCover VPC Network Peering.
  • A central services VPC connected to the transitVPC over HA VPN.

In this design the spokes that are connected using HA VPNuse the transit VPC to communicate with the spokes that areconnected by VPC Network Peering. The communication is steered through thethird-party NVA firewalls by using the following combination of passthrough loadbalancing, static routes, and policy-based routes:

  1. To steer HA VPN traffic to the internal load balancer, applyuntagged policy-based routes to the Transit VPC. On thesepolicy-based routes, use source and destination CIDR ranges that provide fortraffic symmetry.
  2. To steer incoming traffic to the internal passthrough Network Load Balancer, apply policy-based routes tothe Cloud Interconnect connections in the TransitVPC. These are regional routes.
  3. So that traffic leaving the NVA doesn't get routed directly back to the NVA,make all NVA interfaces the target of askip-policy-basedroute to skip other policy-basedroutes. Traffic then follows the VPC routing table once it has beenprocessed by the NVAs.
  4. To steer traffic to the NVA internal load balancers in the TransitVPC, apply static routes to the applicationVPCs. These can be scoped regionally using network tags.

Multi-NIC NVA perimeter security

In multi-NIC mode, the topology is more static because NVAs bridge theconnectivity between the different VPCs in which the differentnetwork interfaces reside.

When interface-based zones are required in a firewall, the following multi-NICdesign enables the required external connectivity. This design assigns differentfirewall interfaces to the external networks. The external networks are referredto by security practitioners as untrusted networks and the internal networks areknown as trusted networks. For the multi-NIC NVA deployment, this design is implementedusing trusted and untrusted VPCs.

For internal communications, firewalling can be enforced using a single-NICinsertion model that corresponds to a CIDR-based zone model.

In this design, you insert NVAs by configuring the following:

  1. To steer HA VPN traffic to the internal load balancer, applyuntagged policy-based routes to the trusted VPC. On thesepolicy-based routes, use source and destination CIDR ranges that provide fortraffic symmetry.
  2. To steer incoming traffic to the internal passthrough Network Load Balancer, apply policy-based routes tothe Cloud Interconnect connections in the untrustedVPC. These are regional routes.
  3. So that traffic leaving the NVA doesn't get routed directly back to the NVA,make all NVA interfaces the target of askip-policy-basedroute to skip other policy-basedroutes. Traffic then follows the VPC routing table once it has beenprocessed by the NVAs.
  4. To steer traffic to the NVA internal load balancers in the trustedVPC, apply static routes to the applicationVPCs. These can be scoped regionally using network tags.

The following diagram shows multi-NIC NVAs inserted between the untrusted andtrusted VPC networks in the hub project:

NVAs for internal communication

What's next

Contributors

Authors:

Other contributors:

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-01-30 UTC.