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:

  1. aws-vpc-site
  2. azure-vnet-site
  3. gcp-vpc-site
  4. 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

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 XC Terraform Examples

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

F5 XC Terraform 

F5 XC App Connect

F5 XC Site Mesh Groups

F5 XC DNS Zone Management

Product Information

F5 XC Network Connect

F5 XC App Connect

Published Jul 12, 2024
Version 1.0
No CommentsBe the first to comment