zecfoundation
/
cloud-foundation-fabric
mirror of https://github.com/ZcashFoundation/cloud-foundation-fabric.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
cloud-foundation-fabric/infrastructure/hub-and-spoke-vpns
History
Ludovico Magnocavallo 253c51d07c
Update docs using tfdoc format (#28) 
* update README files

* set all types on variables
 		2020-01-10 13:44:54 +01:00
..
README.md Update docs using tfdoc format (#28) 2020-01-10 13:44:54 +01:00
backend.tf.sample Rename to hub-and-spoke-vpns 2019-10-30 09:57:33 +01:00
diagram.png Hub and spoke: minimal README changes, update diagram 2019-11-01 10:50:56 +01:00
main.tf Update network module version, add types to the variables 2019-10-31 16:54:43 +01:00
outputs.tf Add README.md, add descriptions to the outputs 2019-10-30 13:51:42 +01:00
provider.tf Add missing bolierplate 2019-10-31 22:05:30 +01:00
terraform.tfvars.sample Rename to hub-and-spoke-vpns 2019-10-30 09:57:33 +01:00
test-resources.tf Add README.md, add descriptions to the outputs 2019-10-30 13:51:42 +01:00
variables.tf Update network module version, add types to the variables 2019-10-31 16:54:43 +01:00

README.md

Hub and Spoke VPNs

This sample creates a simple Hub and Spoke VPN architecture, where the VPC network connects satellite locations (spokes) through a single intermediary location (hub) via IPsec VPN, optionally providing full-mesh networking via custom route advertisements.

NOTE: This example is not designed to provide HA, please refer to the documentation for information on Cloud VPNs and HA.

The benefits of this topology include:

  • Network/Security Admin manages Central Services Project (Hub).
  • Central services and tools deployed in Central Services Project (Hub) for use by all Service Projects (Spokes).
  • Network/Security Admin hands over spoke Projects to respective team who then have full autonomy.
  • Network/Security Admin monitors spoke projects for organization security posture compliance using tools like Forseti, CSCC etc deployed in Central Services Project (Hub).
  • Spokes communicate with on-prem via VPN to transit hub and then over Interconnect or VPN to on-premises (on-premises resources are not included in this sample for obvious reasons).
  • (Optional) Spokes communicate in a full-mesh to each other via VPN transit routing in Central Services Project (Hub).
  • This is a decentralized architecture where each spoke project has autonomy to manage all their GCP compute and network resources.

The purpose of this sample is showing how to wire different Cloud Foundation Fabric modules to create Hub and Spoke VPNs network architectures, and as such it is meant to be used for prototyping, or to experiment with networking configurations. Additional best practices and security considerations need to be taken into account for real world usage (eg removal of default service accounts, disabling of external IPs, firewall design, etc).

High-level diagram

Managed resources and services

This sample creates several distinct groups of resources:

  • three VPC Networks (hub network and two ppoke networks)
  • VPC-level resources (VPC, subnets, firewall rules, etc.)
  • one Cloud DNS Private zone in the hub project
  • one Cloud DNS Forwarding zone in the hub project
  • four Cloud DNS Peering zones (two per each spoke project)
  • one Cloud DNS Policy for inbound forwarding
  • four Cloud Routers (two in hub project and one per each spoke project)
  • four Cloud VPNs (two in hub project and one per each spoke project)

Test resources

A set of test resources are included for convenience, as they facilitate experimenting with different networking configurations (firewall rules, external connectivity via VPN, etc.). They are encapsulated in the test-resources.tf file, and can be safely removed as a single unit.

  • two virtual machine instances in hub project (one per each region)
  • two virtual machine instances in spoke1 project (one per each region)
  • two virtual machine instances in spoke2 project (one per each region)

SSH access to instances is configured via OS Login. External access is allowed via the default SSH rule created by the firewall module, and corresponding ssh tags on the instances.

Known issues

  • It is not possible to get inbound DNS forwarding IPs in the terraform output.
    • Please refer to the bug for more details.
    • Please refer to the documentation on how to get the IPs with gcloud.

Variables

name description type required default
hub_project_id Hub Project id. Same project can be used for hub and spokes. string ✓
spoke_1_project_id Spoke 1 Project id. Same project can be used for hub and spokes. string ✓
spoke_2_project_id Spoke 2 Project id. Same project can be used for hub and spokes. string ✓
forwarding_dns_zone_domain Forwarding DNS Zone Domain. string on-prem.local.
forwarding_dns_zone_name Forwarding DNS Zone Name. string on-prem-local
forwarding_zone_server_addresses Forwarding DNS Zone Server Addresses list(string) ["8.8.8.8", "8.8.4.4"]
hub_bgp_asn Hub BGP ASN. number 64515
hub_subnets Hub VPC subnets configuration. list(object({...})) ...
private_dns_zone_domain Private DNS Zone Domain. string gcp.local.
private_dns_zone_name Private DNS Zone Name. string gcp-local
spoke_1_bgp_asn Spoke 1 BGP ASN. number 64516
spoke_1_subnets Spoke 1 VPC subnets configuration. ...
spoke_2_bgp_asn Spoke 2 BGP ASN. number 64517
spoke_2_subnets Spoke 2 VPC subnets configuration. ...
spoke_to_spoke_route_advertisement Use custom route advertisement in hub routers to advertise all spoke subnets. bool true

Outputs

name description sensitive
hub Hub network resources.
spoke-1 Spoke1 network resources.
spoke-2 Spoke2 network resources.