Skip to main content
This document explains how the Aviatrix platform is secured and how you can harden your deployment to meet security architecture board and compliance reviews. It covers public IP usage, egress controls, cloud-specific security techniques, and recommended configurations for Controllers, Gateways, and CoPilot.
This document does not cover Product Security Assessments, Information Security Policy, Compliance Standards, vulnerability assessments, penetration testing, or source code review. Those materials are available separately under NDA.
The following checklist summarizes the actions you should take to reach a fully hardened deployment: For the full responsibility breakdown, see the Shared Responsibility Matrix at the end of this document.

​
Background

The Aviatrix Controller and Gateway communicate over a management/control plane channel that uses public IP addresses. This secure channel is established during Gateway creation and handles:
  • Gateway health checks
  • Route and policy updates from the Controller
  • Gateway statistics
  • Keepalives in both directions
  • Diagnostic requests from the Controller
Public IP addresses ensure connectivity between the Gateway and the Controller regardless of geographic or CSP location. In addition to the management/control plane channel, Gateways initiate sessions to the internet for Linux package updates, Gateway log uploads, and other operational tasks. You can obtain a comprehensive list of known Gateway activities and their corresponding ports and protocols from Aviatrix, then lock down the outbound security group to only allow permitted activities.

​
Outbound Connection Tables

The following tables list outbound connections initiated by each Aviatrix component. Use them to configure egress security groups.

​
Spoke and Transit Gateway Outbound

​
Controller Outbound

​
CoPilot Outbound

​
Gateway Deployment

The Aviatrix Controller leverages CSP APIs to deploy Gateways into VPCs and VNETs. During deployment, the management/control plane channel is created.
  • The Controller pushes the necessary software packages and begins bi-directional communication.
  • The Controller updates the security group of the instance to only allow TCP/443 from the Controller public IP address, ensuring only the Controller can reach the Gateway over its public IP.
  • IP Forwarding is enabled on the Gateway instance for packet forwarding.
Diagram showing the encrypted channel between Gateways and Controller with security group restricting access to the Controller public IP on TCP 443 The following illustration shows the location of the Gateways within the target state architecture in a hub and spoke design. Architecture diagram showing Transit and Spoke Gateway deployment across AWS and Azure with public and private subnets

​
Azure Spoke Design Options

Aviatrix supports two spoke design options in Azure: with and without Spoke Gateways. Diagram showing Azure spoke design with Aviatrix Peering and VNET Peering options connecting to Aviatrix Transit with egress via FireNet Choose between these options based on your spoke requirements. Each option has tradeoffs in terms of feature availability and deployment complexity.

​
Azure Gateway Security Controls

Aviatrix has compiled several techniques and best practices for securing public IP usage in Azure. These techniques are designed to be layered within your environment to maximize security.

​
Azure Management Groups

Azure management groups allow you to group multiple subscriptions and apply policy at the management group level. Work with Aviatrix to fine-tune Azure policy and simplify policy management within your Azure environment. Azure portal showing Management Groups with subscriptions grouped under a Tenant Root Group

​
Azure Subnet Level Security Group

Azure offers network security groups (NSGs) at the vNIC level and at the subnet level for instance egress protection. You can apply NSGs at the subnet level to specify permitted public IPs for allowing internet egress. NSGs at the vNIC level and the subnet level are combined when determining policy enforcement, and a deny policy at the subnet level blocks the communication regardless of the NSG at the vNIC level. Diagram showing NSG at subnet layer with only permitted public IPs allowed to reach the internet Example NSG rules at the subnet level within the VNET:
  • Aviatrix Gateway public IP a.a.a.a is permitted to go to the internet gateway
  • Aviatrix Gateway public IP b.b.b.b is permitted to go to the internet gateway
  • All other public IPs are denied to go to the internet gateway
You can also leverage NSGs at the vNIC level on the Aviatrix Gateway and use tags to exempt them from the public IP policy. The Aviatrix Controller tags all Aviatrix Gateway instances with “Aviatrix-Created-Resource”. This ensures that virtual machines within a VNET that do not have an Aviatrix tag are not exempt from the policy. Diagram showing NSG at vNIC level with tags applied to Aviatrix Gateway instances to allow public IP exemption

​
AWS Gateway Security Controls

Aviatrix has developed features on the Controller and different AWS techniques that allow the use of public IP addresses on Gateways but do not allow any other internet connectivity.

​
Monitor Gateway Subnet (Controller Feature)

For Aviatrix Spoke Gateways deployed in AWS, the Controller has a built-in feature called Monitor Gateway Subnets. This feature tells the Controller to monitor the subnet where the Gateways are deployed, and if another instance is deployed within that subnet, shut it down. Controller UI showing Monitor Gateway Subnets feature with Enable and Disable buttons This feature allows you to create a single public subnet in two different AZs within an AWS VPC that are used only for the Aviatrix Gateways. All other subnets within the VPC are private, which prevents instances from reaching internet resources out of the IGW. Within this architecture there are private and public subnets and two corresponding route tables. The private RT contains routes programmed by the Controller to send traffic to the Gateways within the VPC. The public RT has a default route to the IGW, and only the subnets with the Aviatrix Gateways use this RT. AWS VPC architecture showing private subnets with EC2 instances routing through a Private RT to public subnets with Aviatrix Gateways in two AZs connecting to the IGW via a Public RT

​
AWS Security Groups

For Aviatrix Gateways deployed in AWS, a security group is created along with the instance and applied to the ENI of the Gateway. By default, the security group has restricted access to only the Controller public IP address on TCP/443.

​
AWS Access Control Lists

For Aviatrix Gateways deployed in AWS, you can use a network access control list (ACL) in addition to the security group to further restrict public access.

​
Post-Release Vulnerability and Patch Management

  • Make ongoing plans for periodic updates to the latest image and software versions.
  • For critical security vulnerabilities such as zero-day exploits, pre-authentication flaws, or remote code execution, Aviatrix releases a hotfix or security patch within industry-standard SLAs. The Aviatrix Product Security Incident Response Team (PSIRT) provides guidance on implementing compensating controls where applicable.
  • Aviatrix continuously leverages multiple industry-leading vulnerability scanning tools to identify CVEs and detect potentially malicious third-party dependencies. All findings are reviewed by the Product Security team to assess impact and prioritize remediation.
  • For each vulnerability, the Aviatrix PSIRT determines whether there is any risk to the Confidentiality, Integrity, or Availability (CIA) of the overall architecture. If there is any risk, the PSIRT Incident Response Process begins.

​
Software Architecture

  • Aviatrix software runs on a standard Ubuntu Linux operating system that is closed, locked down, and hardened to CIS hardening standards.

​
Deployment Security

  • Aviatrix Enterprise deployment operates within your environment. Aviatrix has no access to your data.
  • If you need Aviatrix Customer Support to assist in resolution of an issue, initiate this through the dedicated customer support functionality in the product. You can terminate this access at any time.

​
Configuration Hardening

  • All Aviatrix Controller commands at the console or REST API and events are logged to rsyslog.
  • All Aviatrix Gateway events are logged to rsyslog.
  • SSH access to Controller, CoPilot and Gateway instances is restricted and not exposed by default. If port 22 is manually enabled for troubleshooting purposes, it is the customer’s responsibility to limit access to trusted source CIDRs.
  • The Controller web interface (tcp/443) is, by default, available to the internet. Use security groups to limit access to the Controller to known internal IP addresses.
  • Images are hardened to CIS Server Level 1.

​
Software Update Security

  • Software is only updated from the Aviatrix software repository server when you request a specific command at the Aviatrix Controller.
  • All communication between you and the Aviatrix Controller is protected through TLS.

​
Securing the Aviatrix Controller

​
Enable Additional Controls to Access Controller

​
Reduce Surface Area

  • Only allow TCP/443 from the most limited inbound IPs or CIDR blocks as possible. By default this is open to the internet; reduce this in the CSP Security Groups.
  • Restrict access to the Controller UI to the corporate VPN. If you use Aviatrix VPN, you can whitelist user IPs to allow VPN clients to reach the Controller UI.
  • Deploy a WAF in front of the Controller UI to provide additional application-layer protection and enforce strict access policies.
  • Gateways must have a public IP and their security group must be restricted to the public IP address of the Controller.
  • Use a load balancer and/or WAF in front of the Controller. In Azure, use WAF with Azure Managed rules on Application Gateway to limit usual web attacks against the Controller.
Azure Management VNET showing Gateways connecting to the Controller via Public IP and Network Security Groups, with users routed through an Application Gateway In GCP, an HTTPS load balancer can be used in a similar manner to secure the Controller. GCP architecture showing Controller behind HTTP Load Balancing with Cloud Armor, Identity-Aware Proxy, Cloud DNS, and Cloud Firewall Rules for Transit and Spoke Gateways In AWS, use WAF with AWS Managed rules on ALBs to limit usual web attacks against the Controller. Architecture diagram showing Controller VPC with ALB, WAF, User Access SG, and Gateway SG connecting to Spoke and Transit Gateways

​
Automatic Security Group Management

  • This feature automatically manages the Controller instance inbound rules from the Gateways.
  • When enabled, the Controller immediately creates security groups and allows only specific Aviatrix Gateway to Controller communication.
  • Edit the security rules that are outside the Gateway public IP address to limit the source address range.

​
Use Signed Certificates

  • Aviatrix Controller ships with a self-signed certificate which provides browser warnings for an insecure site (Untrusted Certificate).
  • Replace the self-signed certificate by generating a CSR and importing a certificate, or by importing a certificate with key.

​
Remove Less Secure Versions of TLS

  • Only support TLSv1.2 and above.
  • Disable access from browsers that support TLSv1.0 or TLSv1.1.

​
User Authentication to Controllers

The Controller supports a variety of options for user login. Integrate into your identity platform such as Active Directory, LDAP, or SAML providers. If username and password are required, harden the password requirements and enable 2FA.

​
Enable LDAP Integration for Controller Login

  • Replace standard username/password of local accounts with corporate directory access.
  • Navigate to Settings > Controller > LDAP Login.

​
Enable SAML Login

​
Harden Password Requirements

  • Navigate to Settings > Advanced > Password Management.
  • Change minimum and maximum password length.
  • Reflect corporate password requirements for upper/lower-case, numeric, and special characters.
  • Define the maximum number of days the password is valid.
  • Define the number of passwords in the Password History.
  • Aviatrix Password Management Documentation

​
Enable Duo 2FA

​
Use Role-Based Access Controls (RBAC)

  • Create capabilities in the application required for different role personas to complete their job responsibilities.
  • RBAC limits attack surface area and reduces the potential for catastrophic errors by reducing the operations a specific user can perform.
  • If an account is compromised, the attacker only has access to those capabilities, not the full capabilities of the entire system.

​
Encrypt EBS Volumes

  • Ensure that all non-ephemeral storage is encrypted using CSP-provided capabilities such as AWS EBS volume encryption.

​
Securing Gateways

​
Public Subnet Requirements

  • Use security best practices to only open connectivity to the Gateway from an approved allow list.
  • While deploying transit solutions, CSPs require vendor Gateways to be deployed on public subnets.
  • Aviatrix Transit Gateways in the Transit VPC/vNET establish secure IPSEC tunnels with Spoke VPCs over public IP whether the Spoke VPC/vNET deployed a vendor Gateway or VGW.
  • Although the connectivity patterns leverage public IPs, the path never hits public internet and is routed within the CSP backbone.
  • When the Controller communicates with Gateways or Gateways communicate across Cloud Provider boundaries, this communication is secured at the application layer or uses IPSec as needed.

​
Securing Public Subnets

  • Enable Gateway Subnet Monitoring.
  • When enabled, the Aviatrix Controller monitors selected public subnets periodically.
  • When it detects any instances launched on these subnets, the Controller alerts the admin and stops the instances.

​
Gateway Security Groups and Ports

  • The Aviatrix Gateway instance has strict security group allowances that are only open to the Controller IP on tcp/443 (https).
    • tcp/443 (https) for upgrades from the Controller and diagnostic purposes.

​
Gateway to Gateway IPSec

  • Gateway to Gateway IPSec tunnels require two incoming ports:
    • udp/4500 (Data Channel for IPSec NAT Traversal)
    • udp/500 (Control Traffic for IPSec - ISAKMP)

​
Securing CoPilot

​
Associate Controller with Your CoPilot

Enable the Controller to manage CoPilot Security Groups:
  1. Navigate to Settings > CoPilot > CoPilot Security Group Management.
  2. UDP port 5000 - Enable syslog for CoPilot Egress and Audit Data from each Gateway. Gateways send remote syslog data to CoPilot.
  3. TCP port 31284 - Enable logs for CoPilot Egress and Audit Data from each Gateway. Gateways send remote logs data to CoPilot.
  4. TCP port 5000 (default) - Private Mode Only - Enable Syslog for CoPilot Egress FQDN and Audit Data (from each Gateway). Gateways send remote syslog to CoPilot.
  5. UDP port 31283 (default, configurable) - Enable Netflow for CoPilot FlowIQ Data (from each Gateway). Gateways send Netflow data to CoPilot.

​
Configure SAML

Enhance the login protections to your CoPilot instance using the corporate Identity Provider. See Set Up SAML Login for CoPilot . Additionally, by using the Identity Provider, you can ensure that employees who no longer have access to CoPilot are revoked the moment they are revoked from the Identity Provider. Using username/password requires manual intervention from the corporate IT team or other team managing access to CoPilot.

​
CoPilot Service Accounts

All CoPilot installations require Service Accounts to perform operations with other components of the Aviatrix System. Some of these permissions must be created by the CoPilot system administrator to have minimal permissions to the features:
  • CoPilot ThreatIQ and Distributed Firewalling require CoPilot service to have minimum all_firewall_network_write (Firewall Network permission group) permissions.
  • CoPilot Gateway Scanning requires all_gateway_write (Gateway permission group) permissions.
Full Access can be provided to the service accounts using the all_write (AllWrite permission group), however, this is not best practice as it gives a service account more permissions than needed and does not comply with the principle of least privilege.

​
Controller High Availability in AWS and Azure

​
AWS

Aviatrix Controller and CoPilot HA in AWS leverages Auto Scaling Groups (ASGs), Elastic Container Service (ECS), and supporting AWS services to provide high availability and seamless recovery. The Controller and CoPilot each run in their own ASG. When a new instance is launched, it is initialized to the specified version (latest by default), and Controller backups are configured automatically. An AWS load balancer is configured with both the Controller and CoPilot instances as targets to provide continuous availability. ECS handles Controller and CoPilot failover events. When an ASG event occurs, an Amazon EventBridge rule triggers ECS. ECS then restores the configuration from the latest backup on the new instance, ensuring minimal downtime. Supporting services such as Amazon SNS and SQS integrate with this workflow: ASG events are published to SNS, and the subscribed SQS queue delivers messages to ECS, enabling it to take the appropriate recovery actions. This design ensures that new Controller or CoPilot instances are automatically initialized, configured, and restored whenever a failover event occurs, maintaining availability across Availability Zones. A Controller can be manually launched from a different region and the backed-up configuration can be restored on it. The Controller new EIP should not cause any issues unless SAML VPN authentication is being used. (All peering tunnels will still work). In that case, SAML VPN client will need to reach the Controller IP address. If the FQDN hostname is used for the Controller for SAML, then it should work after changing the Route 53 to resolve to the correct EIP in the different region.

​
Azure

A similar Controller HA design is available in Azure using scale set and load balancer. This solution uses Azure function to manage failover events along with periodic backup if needed.

​
Shared Responsibility Matrix

The matrix below summarizes which security controls Aviatrix already enforces in the product versus the controls you are expected to configure or maintain. Use this as the audit reference when answering an architecture review board.