git repository is distributed in nature, also there are tons of repositories not using terraform. You have just created a killer terraform solution and cannot wait to share with world, instead of trying to send people the git repo link, how about publish it to terraform registry, and now everyone can search and simply use it as a module? After all, let’s keep it DRY (Don’t repeat yourself) as much as possible.
Aviatrix controller is already hardened. You may further lock it down with Settings -> Controller -> Access Security -> Controller Security Group Management. The controller would be protected by Security Group allowing access only from Aviatrix Gateways. Customer can add their own egress public IPs and CoPilot public IPs to security group, allowing inbound HTTPs access to the Aviatrix controller.
Enterprises already utilizing Azure Application Gateway/ WAF may want to place the Aviatrix controller behind it, for tighter security. This blog post shows how to place the Aviatrix controller behind Azure Application Gateway/WAF
When first launched Aviatrix controller from marketplace, the Aviatrix controller give itself a self-signed certificate, and you have to use https://controller-ip to access it, which may not meet compliance requirement.
This blog will talk about getting a public trusted SSL certificate for Aviatrix controller.
Scenario: One of our customers are primary in Azure, after merger and acquisitions, them acquired hundreds of AWS accounts, where workloads are deployed to default VPCs, which all have this address space: 172.31.0.0/16
They are looking for a solution to provide bi-directional private connectivity to these workloads in AWS from Azure without overhead of route management, also provide visibility to the traffic.
Scenario: One of our customers are primary in Azure, after merger and acquisitions, them acquired hundreds of AWS accounts, where workloads are deployed to default VPCs, which all have this address space: 172.31.0.0/16
They are looking for a solution to provide bi-directional private connectivity to these workloads in AWS from Azure without overhead of route management, also provide visibility to the traffic.
When operating in the cloud, enterprises often struggle with how to gain control of network traffic leaving their environments in a centralized, cost-effective, and CSP-agnostic way.
In this webinar, you’ll learn how to make cloud egress architecture simple, repeatable, and automated—including how to:
Gain visibility and control of internet-destined traffic in a cost-effective way (FQDN, subtopics distributed, centralized)
Insert next-generation firewalls into internet-outbound traffic and deal with thousands of route entries
Scale up and scale out your egress firewalls in an active manner and retain existing flows
Plus, the benefits of leveraging Aviatrix FireNet and ThreatIQ, ThreatGuard, and Anomaly Detection.
IAM programmatic access user already setup and working for Terraform in AccountA, let’s call this user Terraform-User, and it already have role assigned in AccountA
Now that we are going to use the same Terraform-User access key and secret to work on resources in AccountB
Create a new role in AccountB
Trusted entity -> AWS account -> since AccountB need to trust AccountA, enter AccountA’s account ID
Assign required permission polices to this role, eg: AdministratorAccess
If you run it, you may find resources gets created in the default account : AccountA, where Terraform-User is resided. How do we make the resource create in AccountB instead?
Think of module a mini block of terraform code that also require it’s own provider block. If you don’t specify anything in /modules/app/providers.tf, it will implicitly have this block, basically it’s looking for a provider called aws
This is telling within the module, provider.aws is equal to root provider.aws.account_b.
If you rerun terraform apply. you will notice:
Resources created in AccountA remains
New resources get created in AccountB now
Warning message:
Warning: Provider aws is undefined
│
│ on main.tf line 8, in module "app1":
│ 8: aws = aws.account_b
│
│ Module module.app1 does not declare a provider named aws.
│ If you wish to specify a provider configuration for the module, add an entry for aws in the required_providers block within the module.
To make Terraform happy, add following lines in /modules/app/providers.tf