IT infrastructure and apps are moving en masse to public clouds – AWS, Azure, Google – understanding leveraging infrastructure as code to provision the network services, connectivity and security to maximize simplicity, security and performance is critical to DevOps success in building and managing the new Enterprise Multi-Cloud Backbone.
In this webinar, you’ll learn more about critical use cases such as (1) Using Terraform to spin up transit networking services in AWS, (2) profile-based secure cloud access for developers, and (3) VPC secure egress filtering to meet compliance, including deeper dives into:
Deploying the network as code using automation tools
Addressing specific operational challenges for high availability, across multiple VPCs
Isolating environments for dev and test easily
Design pattern details and the pros and cons of each approach
Understanding the limitation of native services and how to add value and capabilities with advanced services
How to architect an Enterprise Multi-Cloud Backbone to support all your cloud use case
2. 21 Years in Information Technology
- Administration / Networking
- Design / Development / Cloud
10 Years in the InfoSec Space
- Application / Mobile Security
- Infrastructure / SIEM / Risk
Python Coder – PyCharmMark Cunningham
Senior Solutions Architect
markc@Aviatrix.com
3. In this webinar, you’ll learn more about critical use cases such as:
1. Using Terraform to spin up transit networking services in AWS
2. Profile-based secure cloud access for developers
3. VPC secure egress filtering to meet compliance
including deeper dives into:
• Deploying the network as code using automation tools [terraform
• Addressing specific operational challenges for high availability, across multiple VPCs [HA peering, HA Egress]
• Isolating environments for dev and test easily
• Design pattern details and the pros and cons of each approach
• Understanding the limitation of native services and how to add value and capabilities with advanced services
• How to architect an Enterprise Cloud Backbone to support all your cloud use cases
Webinar Brief – DevOps.com
5. Aviatrix Confidential
Meet Michael…
Michael is a developer. He has an idea for an application that will make
use of his company’s data. An application that capitalizes upon the
opportunity present in last minute cancellations of airline tickets and
hotel rooms that haven’t sold yet.
He gets sign off from his manager who approves a small budget for him
and gives him read access to the company data lake.
He designs a quick query and scoops up a few chunks of data for specific
time periods and begins work on his application. All the while, he is
wondering how he is going to access his application server in the cloud,
so he googles ‘coolest AWS VPN solution ever’ and AVX is the top result.
Quickly, he learns that he can deploy the entire solution as code after
laying the groundwork for a few needed components in AWS. So he
decides to go that route, and off he goes!
6. Aviatrix Confidential
Installing Terraform + AVX provider
In case you are new to Terraform….
Install Terraform
NinjaMac:~ brew install terraform
Install Go
NinjaMac:~ brew install go
Set the Go path:
NinjaMac:~ ( ~/.bash_profile) export GOPATH=$HOME/go
Clone the Provider Repo and build it
NinjaMac:~ git clone https://github.com/AviatrixSystems/terraform-provider-aviatrix
$ cd $GOPATH/src/github.com/terraform-providers/terraform-provider-aviatrix
$ make fmt
$ make build
Create Terraform Configuration file with a provider entry for AVX
NinjaMac:~ touch ~/.terraformrc
providers {
"aviatrix" = "$GOPATH/bin/terraform-provider-aviatrix"
}
https://docs.aviatrix.com/HowTos/tf_aviatrix_howto.html
7. Aviatrix Confidential
Launch the Controller
To get the controller launched, you need:
• A centrally located VPC, usually Shared Services in a Prod, or Non-Prod account
• A public subnet
• An available EIP
Two ways you can launch it:
§ Script Only https://github.com/AviatrixSystems/terraform-modules
§ AWS Markplace AMI
8. After Michael launches the controller and gets the AVX provider configured, he begins building his
VPN Endpoint with Terraform
provider "aviatrix" {
controller_ip = ”XXX.XXX.XXX.XXX"
username = "admin"
password = “Open-Sesame”
resource "aviatrix_gateway" "AVX-VPN-GW" {
account_name = "MarksDemoAccount"
cloud_type = 1
gw_name = "AVX-VPN-GW"
vpc_id = "vpc-045d528779bd37a10"
vpc_reg = "us-west-2"
vpc_size = "t2.small"
vpc_net = "10.21.150.0/24"
vpn_access ="yes"
vpn_cidr ="192.168.43.0/24"
}
<<aviatrix>>
User VPN service
+
AWS cloud
Seattle office
AVX Controller
VPC
AVX User VPN Gateway
9. resource "aviatrix_gateway" "AVX-VPN-GW" {
account_name = "MichaelsDemoAccount"
cloud_type = 1
gw_name = ”Michaels-VPN-GW"
vpc_id = "vpc-045d528779bd37a10"
vpc_reg = "us-west-2"
vpc_size = "t2.small"
vpc_net = "10.21.150.0/24"
vpn_access ="yes"
vpn_cidr ="192.168.43.0/24"
}
<<aviatrix>>
resource "aviatrix_vpn_user" "terraform_vpn_user"
{
vpc_id = "vpc-045d528779bd37a10"
gw_name = "AVX-VPN-GW"
user_name = "mark1"
user_email = "superman@aviatrix.com"
}
<<aviatrix gateway AVX-VPN-GW>>
User VPN service
+
AWS cloud
Seattle office
AVX Controller
VPC
AVX User VPN Gateway
Now that he has the Controller up and running, he begins moving through the contents of the
terraform provider and collects the required script syntax for deploying a VPN endpoint.
10. <<aviatrix>>
resource "aviatrix_vpn_user" "terraform_vpn_user"
{
vpc_id = "vpc-045d528779bd37a10"
gw_name = ”Michaels-VPN-GW"
user_name = ”Michael-1"
user_email = ”Michael.Baxter@SomeTravelCompany.com"
}
<<aviatrix gateway AVX-VPN-GW>>
resource "aviatrix_vpn_profile" "test_profile1" {
name = "Terraform_Profile"
base_rule = "allow_all"
users = ["mark1"]
policy = [
{
action = "deny"
proto = "tcp"
port = "443"
target = "10.0.0.0/32"
},
{
action = "deny"
proto = "tcp"
port = "443"
target = "10.0.0.1/32"
}
<<aviatrix vpn user terraform vpn user>>
User VPN service
+
AWS cloud
Seattle office
AVX Controller
VPC
AVX User VPN Gateway
Now that he has the Controller up and running, he begins moving through the contents of the
terraform provider and collects the required script syntax for deploying a VPN endpoint.
11. provider "aviatrix" {
controller_ip = ”XXX.XXX.XXX.XXX"
username = "admin"
password = “Open-Sesame”
resource "aviatrix_gateway" "AVX-VPN-GW" {
account_name = "MarksDemoAccount"
cloud_type = 1
gw_name = "AVX-VPN-GW"
vpc_id = "vpc-045d528779bd37a10"
vpc_reg = "us-west-2"
vpc_size = "t2.small"
vpc_net = "10.21.150.0/24"
vpn_access ="yes"
vpn_cidr ="192.168.43.0/24"
}
<<aviatrix>>
resource "aviatrix_vpn_user" "terraform_vpn_user"
{
vpc_id = "vpc-045d528779bd37a10"
gw_name = "AVX-VPN-GW"
user_name = "mark1"
user_email = "superman@aviatrix.com"
}
<<aviatrix gateway AVX-VPN-GW>>
resource "aviatrix_vpn_profile" "test_profile1" {
name = "Terraform_Profile"
base_rule = "allow_all"
users = [”Michael-1"]
policy = [
{
action = "deny"
proto = "tcp"
port = "443"
target = "10.1.0.0/24"
},
{
action = "deny"
proto = "tcp"
port = "443"
target = "10.2.0.168/32"
}
]
}
<<aviatrix vpn user terraform vpn user>>
User VPN service
+
AWS cloud
Seattle office
AVX Controller
VPC
AVX User VPN Gateway
Now that he has the Controller up and running, he begins moving through the contents of the
terraform provider and collects the required script syntax for deploying a VPN endpoint.
12. A close up look at the way the AVX VPN endpoint enables profile based access – what is the profile,
how does it work?
resource "aviatrix_vpn_profile" "test_profile1" {
name = "Terraform_Profile"
base_rule = "allow_all"
users = [”Michael-1"]
policy = [
{
action = "deny"
proto = "tcp"
port = "443"
target = "10.1.0.0/24"
},
{
action = "deny"
proto = "tcp"
port = "443"
target = "10.2.0.168/32"
}
]
}
+
AWS cloud
Seattle office
AVX Controller
VPC
AVX User VPN Gateway
User VPN service
13. Integrates VPN access and VPC peering from a central console
Access Control based upon policies
+
AWS cloud
AVX Controller
VPC
AVX User VPN Gateway
NLB
VNet
Azure cloud
GCP cloud
VPC
Seattle office
Partner EmployeeContractor
Duo
Okta
Active Directory
SAML Client
MFA Authentication
Authorization
User VPN service
42. +
Egress Security
• Distributed Egress
• Centralized Egress
• Hypergress Model
Egress
Security
Feature 3
Feature 2
Feature 1
• Egress Security is in place to give your
development and production servers
access to the internet in a controlled,
policy driven manner that builds on the
NAT gateway concept but offers rules
based off of FQDNs as opposed to IP
addresses
• There are several different operational
models that you can use to deploy our
Egress Filtering Gateways from an
operational perspective –
Distributed is one gateway per VPC,
giving each of the private subnets in that
VPC an automatic route to the ENI of the
Egress Gateway
43. +
Egress Security
• Distributed Egress
• Centralized Egress
• Hypergress Model
Egress
Security
• Egress Security is in place to give your
development and production servers
access to the internet in a controlled,
policy driven manner that builds on the
NAT gateway concept but offers rules
based off of FQDNs as opposed to IP
addresses
• There are several different operational
models that you can use to deploy our
Egress Filtering Gateways from an
operational perspective –
Distributed is one gateway per VPC,
giving each of the private subnets in that
VPC an automatic route to the ENI of the
Egress Gateway
46. The necessity of
Transit evolves…
AWS Cloud
Seattle –
Office
Aviatrix
User_VPN
Gateway
AVX Encrypted
Peering
Feature 2Feature 1 Feature 3 Change structure in first transition slide:
1. Transit?
2. More User VPN configs?
3. Site2Cloud connection to on-prem
Michael now needs to create a few VPCs in his account and give the
other teams access to them such they can begin development on the
new features for his app. He will also need to provide VPN access to
those teams such that they can login to their respective workspaces
and be able to commit their code to his production server while
following the encryption mandate.
47. Enabling HA
AWS Cloud
Seattle –
Office
Aviatrix
User_VPN
Gateway
AVX Encrypted
Peering
Feature 2Feature 1 Feature 3 HA story
1. How it came about – someone from the cloud infra team
2. What he needed to do to modify his template to enable HA
3. The differences between the HA in the different components
4. The expected failover behavior model
The scripts that we are adding to the
48. Transit Continues
to evolve….
AWS Cloud
Seattle –
Office
Aviatrix
User_VPN
Gateway
AVX Encrypted
Peering
Feature 2Feature 1 Feature 3 Story of how Michaels transit solution evolves into a TGW based
transit solution
More VPCs, security domains, etc.
49. Egress Filtering
Part
AWS Cloud
Seattle –
Office
Aviatrix
User_VPN
Gateway
AVX Encrypted
Peering
Feature 2Feature 1 Feature 3 Story of how Michaels transit solution evolves into a TGW based
transit solution
More VPCs, security domains, etc.
50. App/Web VPC
Bank 1
Application
Component
Subnets
Aviatrix
Controller
AWS Peering
VPC 1
Bank 2
Bank N
The Summit Group
AVX Implementation
10.0.0.0/16
• Discreet Site2Cloud VPN Connections can be created from within the
App/Web VPC Gateways
• A Mapped S2C Connection with SNAT/DNAT will need to be employed to
manage the overlapping CIDR ranges ( More details will be needed for final
configuration )
• No intermediary Transit VPC or Gateways are needed between the
App/Web VPC and the banking locations.
• Prescriptive guidance can be found in the listed articles:
• https://docs.aviatrix.com/HowTos/s2c_o
verlapping_subnets.html
• https://www.aviatrix.com/answers/how-
do-i-resolve-conflicts-with-data-center-
ip-and-public-cloud-ip-address-ranges-
using-aviatrix/
• https://www.aviatrix.com/answers/how-
to-test-aviatrix-transit-vpc-for-aws-
without-requiring-a-connection-to-your-
data-center/
52. Proposed Solution - Aviatrix Software-Defined Cloud Router
1. Advanced Mode Transit Gateway
• Support transitive routing from on-prem to AWS environment
• Segmentation through Zero-trust architecture by design. Spoke VPCs cannot talk with each other
through the transit.
• Support a fully encrypted network in the hub and spoke architecture
1. Insane Mode:
• Integrated into the Transit Network to provide 10Gbps performance between On-Premises and
Transit VPC with encryption
• Encryption over Direct Connect
• For Transit VPC Peerings (VPC to VPC), Insane mode can achieve 20Gbps
• Overcome VGW performance limits and 100 route limit
2. Transit DMZ:
• Transit VPC running in Transit DMZ Mode to enable scalable cloud firewall deployment for
Ingress/Egress inspection. Security and Networking functions decoupled to allow independent
scalability.
3. Automation performed through Terraform:
• Aviatrix Controller and Gateways can be automated through the use Terraform.
53. WIZARDS OF THE COAST – AWS Multi-Region
VPC 1
Transit VPC
(Aviatrix Edge)
On-Premise
US-WEST-1 Region
VPC 2
AWS Transit
Gateway
VPC N VPC 1
Transit VPC
(Aviatrix Edge)
On-Premise
VPC 2
AWS Transit
Gateway
VPC 3
US-EAST-1 Region
Backup VPN Backup VPN
Aviatrix
Controller
Shared
Services VPC
Build list
1 egress filters
1 tgw attachments
1 region
54. Potential Capabilities
1. Egress Filtering
• Replace AWS NAT Gateway with policy based NAT Gateway. Aviatrix goes beyond IP-based
filtering to include FQDN filtering across TCP and UDP traffic including HTTP, HTTPS and SFTP
traffic.
2. User VPN
• Aviatrix provides a cloud native and feature rich client VPN solution. The solution is based on
OpenVPN® and is compatible with all OpenVPN® clients. In addition, Aviatrix provides its own
client that supports SAML authentication directly from the client.
• The Aviatrix VPN solution is the only VPN solution that provides SAML authentication from the
client itself. The solution is built on OpenVPN. The Aviatrix VPN Client provides a seamless user
experience when authenticating a VPN user through a SAML IDP. The client also supports
password based authentication methods as well.