Automate Multicloud Networking w/ Terraform: routing and app connect on F5 Distributed Cloud
Introduction
Apps are comprised of many smaller services. Often, apps use services spread across different locations. Different regions might have companies specializing in specific services. An app developer might use a map service from a company in Europe, a payment processing service from the US, and cloud storage from Asia – all within a single app. Services in certain locations might be more cost-efficient. Developers can benefit from this by using them without sacrificing functionality. Regulations regarding data privacy can vary by location, and an app might use services that comply with specific regional regulations to ensure user data is protected. Services offered in multiple locations can provide better redundancy and scalability for the app.
The need for NetOps and DevOps teams to rapidly deploy infrastructure and deliver complex apps, including their dependent services from multiple locations while also keeping everything secure is paramount.
Here are some examples of apps with distributed services:
- Online Banking: Financial institutions leverage distributed systems for secure online banking services. This includes user authentication, transaction processing, and account management – all happening across geographically distributed servers.
- E-commerce Platforms: Amazon, eBay, and other online retailers use distributed services for various functions like product listings, shopping carts, and order processing. This enables them to handle high traffic volumes during peak shopping seasons.
- Payment Processing: Services like Stripe (US) and Adyen (Netherlands) handle secure online transactions for apps globally.
- Scientific Computing: Large-scale scientific research projects often utilize distributed computing for tasks like protein folding simulations or weather forecasting. These projects require immense processing power, which can be achieved by harnessing the combined power of multiple computers across different locations.
The next time you use an app, it may be the result of a complex collaboration between multiple service providers working together behind the scenes from various locations. Connecting many services belonging to a distributed app in a secure and automated way is no easy feat. F5 Distributed Cloud (XC) uniquely solves this challenge by making it ridiculously easy to connect any app, anywhere, and deliver it optimally to anyone regardless of region.
Solution Overview
This article shows how using automation with Distributed Cloud can deploy infrastructure, connect an app, secure it, and deliver it with services running in multiple public cloud environments. By orchestrating the integration of services in different cloud providers and by using Distributed Cloud Customer Edge (CE) Sites, Network Connect, App Connect, and F5’s Global Network, together with HTTP security and enhanced firewall rules, F5 XC streamlines the deployment and management in hybrid environments.
This is an automation-exclusive solution intended for NetOps and DevOps teams in large enterprise organizations.
This fully automated end-to-end solution workflow in GitHub uses F5 XC with Customer Edge (CE) sites deployed in AWS, Azure, and GCP to provide network-centric connectivity to the services in running on each site, and app-centric connectivity for traffic ingress.
To provide an example of the modern distributed app, Arcadia Finance, this workflow creates and/or manages resources in the following cloud providers:
- AWS
- Azure
- GCP
This workflow also has the following automation-dependent infrastructure requirements:
- Hashicorp Terraform Cloud
- Account
- GitHub
- Account
- Fork/Clone f5-xc-terraform-examples repo
- Add to your repo: secrets and variables, all cloud credentials, network settings, as defined in the workflow guide
This distributed app is comprised of four services, three of which run in different locations.
The main app and backend run in AWS; the money transfer app in Azure, and the refer a friend app in Google Cloud. Main calls out to both the backend and money transfer for data and formatting. The API in the money transfer app can be used independently, and when accessed directly, calls out to the remote backend for data.
Connectivity between the services is delivered two ways: 1) App-centric: users access the app with an App Connect HTTP LB that provides Layer7 connectivity to the main and money transfer apps, 2) Network-centric: the apps in different locations communicate internally and use a full-mesh Site Mesh Group. Routing between the sites is direct (CE to CE), however, if direct connectivity isn’t available (not depicted), traffic can go via the Global Network (CE to RE to CE).
Automation Workflow
Accounts and Settings
Distributed Cloud (XC)
A tenant in F5 XC is needed to orchestrate this workflow and deliver the application. Under tenant administration, add new credentials with type API Certificate, and save both the p12 file and password to use later in GitHub.
Terraform Cloud
A HashiCorp account is required to maintain a state in Terraform Cloud. Using a HashiCorp account, go to app.terraform.io and create a new organization. Configure this organization with the setting: default execution mode “Local”. Next, create either an organization-based or a user-based API token. Both the token and name of the organization will be used by the automation workflow to create workspaces and store the infrastructure state.
GitHub
Using a personal or enterprise GitHub account, fork the main repo f5devcentral/f5-xc-terraform-examples. Next, configure all the variables to access your cloud accounts and deployment parameters, such as the region and which IP addresses to use, as well as the fully qualified domain-name (FQDN) to publicly access the app.
AWS
Both an access key id and its secret will be needed by GitHub and F5 XC to provision infrastructure and deploy a CE site. Create and save these to enter in GitHub as repository secrets.
Azure
Both GitHub and F5 XC use an app registration for Terraform to provision infrastructure and deploy a CE site. Create a new app registration and save the client id and secret to configure in GitHub. Additional permissions need to be added to the app registration and are listed in the GitHub workflow README.
GCP
A service account will be used by both F5 XC and GitHub. Create this and assign the needed IAM roles detailed in the workflow README.
The following tables are the complete list of the environment variables and secrets required to complete the workflow.
GitHub Action Secrets
Variable |
Description |
AWS_ACCESS_KEY |
AWS Access Key ID |
AWS_SECRET_KEY |
AWS Secret Access Key |
AZURE_CLIENT_ID |
Azure Client ID |
AZURE_CLIENT_SECRET |
Azure Client Secret |
AZURE_SUBSCRIPTION_ID |
Azure Subscription ID |
AZURE_TENANT_ID |
Azure Tenant (entranet directory) ID |
GOOGLE_ACCOUNT_ID |
Google Account ID |
GOOGLE_CREDENTIALS |
Credentials to access GCP service account JSON (base64encoded) |
GOOGLE_PROJECT_ID |
Existing GCP project id |
TF_API_TOKEN |
Terraform Cloud API Token |
TF_CLOUD_ORGANIZATION |
Terraform Cloud Organization |
XC_API_P12_FILE |
F5 XC P12 certificate (base64encoded) |
XC_API_URL |
F5 XC tenant-specific API URL (example: https://yourtenant_here.console.ves.volterra.io/api) |
XC_P12_PASSWORD |
F5 XC certificate password |
GitHub Action Environment Variables
Variable |
Default Value |
Description |
TF_VAR_name |
"secure-mcn" |
The name of the Deployment |
TF_VAR_prefix |
"" |
The prefix for the Deployment |
TF_VAR_tags |
"{"project": "teachable"}" |
The tags associated with the resources |
TF_VAR_aws_vpc_site_name |
"aws-vpc-site" |
The name of the AWS VPC site |
TF_VAR_aws_region |
"us-east-1" |
The AWS region |
TF_VAR_aws_az_names |
"["us-east-1a"]" |
The AWS availability zone names |
TF_VAR_aws_inside_subnets |
"["10.10.11.0/24"]" |
The inside subnets for the AWS VPC |
TF_VAR_aws_outside_subnets |
"["10.10.31.0/24"]" |
The outside subnets for the AWS VPC |
TF_VAR_aws_workload_subnets |
"["10.10.21.0/24"]" |
The workload subnets for the AWS VPC |
TF_VAR_aws_vpc_cidr |
"10.10.0.0/16" |
The CIDR block for the AWS VPC |
TF_VAR_aws_vpc_cidr_prefix |
"10.10.0.0" |
The CIDR prefix for the AWS VPC |
TF_VAR_aws_vpc_cidr_plen |
"16" |
The CIDR prefix length for the AWS VPC |
TF_VAR_azure_vnet_site_name |
"azure-vnet-site" |
The name of the Azure VNet site |
TF_VAR_azure_location |
"centralus" |
The Azure location |
TF_VAR_azure_resource_group_name |
"" |
The name of the Azure resource group |
TF_VAR_azure_inside_subnets |
"["172.10.21.0/24"]" |
The inside subnets for the Azure VNet |
TF_VAR_azure_outside_subnets |
"["172.10.31.0/24"]" |
The outside subnets for the Azure VNet |
TF_VAR_azure_vnet_cidr |
"172.10.0.0/16" |
The CIDR block for the Azure VNet |
TF_VAR_azure_vm_private_ip |
"172.10.21.200" |
The private IP for the Azure VM |
TF_VAR_gcp_slo_cidr |
"100.64.96.0/22" |
The CIDR block for the GCP SLO |
TF_VAR_gcp_sli_cidr |
"10.3.0.0/16" |
The CIDR block for the GCP SLI |
TF_VAR_gcp_proxy_cidr |
"100.64.100.0/24" |
The CIDR block for the GCP proxy |
TF_VAR_cluster_cird |
"100.64.96.0/24" |
The CIDR block for the cluster |
TF_VAR_services_cird |
"100.64.97.0/24" |
The CIDR block for the services |
TF_VAR_gcp_region |
"us-central1" |
The GCP region |
TF_VAR_namespace |
"" |
The namespace for the Terraform variable |
TF_VAR_app_domain |
"arcadia-mcn.demo.internal" |
The FQDN for the application frontend |
TF_VAR_f5xc_sd_sa |
"smsn-sd-sa" |
The F5 XC SD SA |
TF_VAR_xc_mud |
"true" |
The XC Malicious User Detection setting |
TF_VAR_xc_ddos_def |
"true" |
The XC DDoS defense setting |
TF_VAR_xc_bot_def |
"true" |
The XC Bot defense setting |
TF_VAR_dns_origin_pool |
"true" |
The DNS origin pool setting |
(Optional) Existing F5 XC Cloud Credentials (pre-configured for each cloud provider)
Variable Name |
AWS_CLOUD_CREDENTIALS_TF_VAR_name |
AZURE_CLOUD_CREDENTIALS_TF_VAR_name |
TF_VAR_xc_gcp_cloud_credentials |
Deployment: Order of Operations
Using GitHub Actions, open the “Secure MCN Apply” action and run each of the following deployment modes consecutively:
- aws-vpc-site
- azure-vnet-site
- gcp-vpc-site
- deploy-resources
1. aws-vpc-site
- Run jobs
- New/existing VPC
- New/existing 3 IPv4 subnets
- New F5 XC Cloud CE VM
- Route table management
2. azure-vnet-site
- Run jobs
- New/existing resource group
- New/existing VNet
- New/existing 3 IPv4 subnets
- New F5 XC Cloud CE VM
- User-defined route table management
3. gcp-vpc-site
- Run jobs
- New/existing VPC
- New/existing 4 IPv4 subnets
- 3 subnets for Cloud CE
- 1 subnet for K8s ingress proxy load balancer
- New/existing service account
- New F5 XC Cloud CE VM
4. deploy-resources
- Run jobs
- AWS
- New/existing EKS cluster
- New NGINX+ k8s ingress controller
- Remote services registration in EKS K8s coredns-custom configmap
- Example distributed app workloads: Arcadia Finance (main and files)
- Azure
- New/existing AKS cluster
- New ALB K8s ingress controller
- Remote services registration in AKS K8s coredns-custom configmap
- Example distributed app workload: Arcadia Finance (api)
- GCP
- New/existing GKE cluster
- New GKE K8s Proxy Load Balancer
- Example distributed app workload: Arcadia Finance (refer-a-friend)
- Distributed Cloud (F5 XC)
- Create/connect Global Network with all CE’s
- Create/connect direct CE to CE network path with a full-mesh Site Mesh Group
- Create/deploy Enhanced Firewall Policy to only allow specific app-related traffic between sites
- Create app ingress HTTP LB on RE using local CE’s to proxy inbound connections to service origins in AWS and Azure
- AWS
With all jobs completed successfully, we can now access the application at the FQDN configured for the workflow.
Bonus: When Distributed Cloud is also configured as a Primary DNS for the domain name, and HTTP LB managed records is enabled, the FQDN will automatically be registered in DNS and can be resolved publicly, enabling access the frontend app over the Internet with zero manual configuration.
Conclusion
This automation-based workflow is just one in a series of workflows available in our F5 XC Terraform Examples repo on GitHub. All the Terraform modules in the repo are open source and are designed to be reusable and can be customized and repurposed to work in even the most unique environments. More information is available in this technical article F5 Distributed Cloud, from manual configuration to Terraform automation, showing how to use and change the other workflows in this repo.
With the need to secure, connect, and deliver apps composed of services in multiple environments, an automation-based workflow saves time by routinely building and deploying infrastructure. Using Terraform with F5 XC to build hybrid cloud environments ensures accuracy by uniformly configuring the connectivity and security policies.
Additional Resources
GitHub
F5 Hybrid Security Architectures
DevCentral Technical Articles (related)
Complete Multi-Cloud Networking walkthrough with F5 XC
Introducing Secure MCN features on F5 XC
Use F5 Distributed Cloud to control Primary and Secondary DNS
Product Documentation
Product Information