Quick Overview

The Aviatrix Cloud Network Platform consists of a centralized controller that is multi-cloud aware, intelligent cloud routers called gateways, and CoPilot, a day 2 platform providing visibility and analytics. An example of an Aviatrix managed deployment is provided below.

The diagram below depicts the design I’m going to detail in the next sections:

• Aviatrix controller is exposed as a backend service through a external HTTPs classic load balancer
• the Load Balancer also protects the Controller against L2/L3/L4 exhaustion attacks
• Cloud DNS provides name resolution to the front end IPs of the load balancer
• Google Certificate Authority is used to manage and issue web server certificate to the load balancer
• Cloud Armor is used to provide DDoS protection and WAF

A high level diagram of the solution follows:

Aviatrix recently launched its Controller and CoPilot platform on GCP marketplace with two licensing models:

Infrastructure Configuration for Controller Deployment

• Aviatrix Controller _is_ deployed in an existent VPC in a public subnet behind an External Load Balancer.
• The LB is optional but included in this design to provide an extra layer of protection integrating it with Cloud Armor (WAF).

The terraform tf files can be downloaded from the link provided at the end of this doc.

Controller Deployment

We can deploy Aviatrix directly from the Marketplace. I’ll use the BYOL offer:

I’ll use the defaults:

I’m going to deploy a controller in the gcp-mgmt vpc and gcp-mgmt-us-east1 subnet I created before:

I can see what is going on with the deployment using the Deployment Manager console:

Once the deployment finishes successfully we can move on to the configuration.

Controller Configuration

Ephemeral external and internal IP addresses have been assigned to the VM instance during the deployment but we want them static.

Promoting an ephemeral external IP address to reserved does not cause Google Cloud to drop packets sent to the instance.

Browse to the EIP of the Controller instance. Username is admin and the default password is the private IP address:

Provide a valid email address as a mechanism to recover and or reset the admin password.

Set the admin password using password best practices:

If a proxy is required to internet access, configure it at this time (or later):

The next step is the controller initial setup where the software is downloaded and installed:

Once the initial setup finishes setting up the software, the Controller is ready for its initial configuration and day 0 best practices:

Apply Security Patches:

Apply Software Patches:

Licensing if using BYOL:

Create account(s):

• The Aviatrix Controller is a multi-cloud and multi-accounts platform. The Controller uses your cloud provider API credentials to make API calls, for example, to launch an Aviatrix gateway instance, on behalf of your cloud accounts.
• One cloud credential is represented as an Aviatrix access account on the Controller.

Enable backup (create a bucket first):

Create a read-only user for CoPilot:

Create a user with admin privileges:

Disable Admin Login:

Enable Controller Security Group Management to automatically manage the Controller instance’s inbound rules from gateways:

After this feature is enabled, you can now edit the security rules that are outside gateways public IP addresses to limit the source address range.

wow! we are ready to start configuring our gcp cloud networking.

CoPilot Deployment

For more information on CoPilot, please check my previous post at https://rtrentinsworld.com/2022/05/28/taking-the-left-seat-of-your-cloud-deployment-with-aviatrix-copilot/

CoPilot is deployed from the Marketplace as well:

Instance size (I am going to use the default for my lab environment):

Don’t forget to change the network (default) to the vpc and subnet(s) created before:

Once finished providing the inputs, click Deploy at the bottom of the page and track the deployment using Deployment Manager:

Copilot Configuration

Ephemeral internal and external IP addresses have been assigned to the VM instance during the deployment but we want them static.

Promoting an ephemeral external IP address to reserved does not cause Google Cloud to drop packets sent to the instance.

Browse to the EIP and provide the Controller credentials and IP address:

Once the info is validated, provide the username and password for the user created for the CoPilot integration:

And finally the license (if using BYOL):

The first task after providing credentials, controller ip, and license is to add a data volume:

If not done before, create and attach a new disk to the CoPilot instance and return to the CoPilot Data Disk Setup:

CoPilot will automatically detect and configure additional disks:

The last step is to go back to the Controller and configure CoPilot IP address information to syslog:

A total of 10 profiles from index 0 to 9 are supported for remote syslog, while index 9 is reserved for CoPilot.

And netflow:

Also we can associate the CoPilot to the Controller to log in from the Controller to CoPilot without providing credentials (second icon at the top left corner from right to the left):

Cloud Armor Overview

Cloud Armor provides DDoS protection against network or protocol-based volumetric DDoS attacks for applications behind external HTTP(S) load balancers. It is able to instantly detect and mitigate network attacks in order to allow only well-formed requests through the load balancing proxies.

Backend services behind an external HTTP(S) load balancer also have access to security policies to enforce custom Layer 7 filtering policies, including pre-configured WAF rules to mitigate the OWASP Top 10 web application vulnerability risks.

Cloud Armor protects resources include the following backend types:

I’m going to deploy an external HTTP(S) load balancer in front of my Controller.

Load Balancer Configuration

Instance Group

We create a New Unmanaged Instance Group containing the controller we deployed and configured previously:

A “named” port is required to send traffic to instance group through from the HTTP Load Balancer (I named it https):

Once the instance group is created we can move to the Load Balancer.

Load Balancing

GCP supports a considerable amount of load balancers covering almost if not all scenarios. A summary is provided on the diagram below:

I’m going to adopt a Global External Load Balancer with a standard network tier. External HTTP(S) Load Balancing is a proxy-based Layer 7 load balancer that distributes HTTP and HTTPS traffic to backends hosted on Compute Engine. It is global in Premium Tier but can be configured to be regional in Standard Tier.

This diagram shows the components of a regional external HTTP(S) load balancer deployment:

Name Resolution

I’m using Cloud DNS for name resolution. I created an A record for controller pointing to the LB front-end IP address.

Certificate Management

I’m using GCP Certificate Authority Service from where I created a certificate to use in the HTTP(S) LB:

HTTPS LB Configuration

From the Network Services we pick the Load Balancing from the left panel:

The HTTP(S) Load Balancing wizard guide us through the configuration:

First step is the backend configuration:

We use the previously created instance group for the Backend creation:

Health check creation:

I’m going to return later to reconfigure the backend adding Cloud Armor policies.

Once the backend is configured, we have to configure the path rules:

Front End Configuration:

Front End Certificate Configuration:

Google Managed Certificate is not supported when using network standard tier. The certificate and keys should be manually uploaded and managed.

Cloud Armor Configuration

A Google Cloud Armor security policy rule consists of a match condition and an action to take when that condition is met. Conditions can be as simple as whether the incoming traffic’s source IP address matches a specific IP address or CIDR range (also known as IP address allowlist and denylist rules).

Alternatively, by using the Google Cloud Armor custom rules language reference, you can create custom conditions that match on various attributes of the incoming traffic, such as the URL path, request method, or request header values.

When an incoming request matches a condition in a security policy rule, Google Cloud Armor allows, denies, or redirects the request, based on whether the rule is an allow rule, a deny rule, or a redirect rule.

I’m going to create a rule allowing my Mac to access my gcp Controller and denying anything else. Later I’ll remove my IP from the policy to test it:

The policy I created looks like this:

The format for ranges is IP Address/Mask

We can also enable the Adaptive Protection that learns normal traffic patterns, detecting and alerting on potential attacks, and providing Cloud Armor WAF rules to mitigate them:

The last step is to attach to policy to the HTTP(S) backend:

Testing

I pointed my browser to the FQDN of my HTTP(S) front end and I was able to reach out to the Controller:

Removing my ip address from the Armor policy blocks my access to the controller as expected.

Revisiting Firewall Rules

Once the LB is properly configured, we can revisit the vpc firewall rules for controller and copilot:

• TCP port 443 needs to be opened for inbound traffic to the Controller from gateways, CoPilot, and HTTP(S) LBs.
• For the health check probes, the firewall rule must allow the following source ranges: 130.211.0.0/22 and 35.191.0.0/16.
• You might want to include your own IP.

References

https://cloud.google.com/architecture/partners/aviatrix-cloud-networking-for-gcp