Custom AWS Cloudformation Resource Types for Aviatrix

• 1. Deploy the execution environment
• 2. Install the prerequisites
• 3. Pull and run the Lambda Python image in Docker
• 4. Generate the Aviatrix resources and provider documentation
• 5. Submit the resources to AWS Cloudformation
• 6. Configuring Aviatrix Controller IP address and credentials
• 7. Deploy resources by creating a Cloudformation template

This repository provides the code and guide for deploying custom Aviatrix resources using AWS CloudFormation.

Prerequisites

The Aviatrix controller should be deployed before creating the network infrastructure. If you're starting from scratch, you can use example-avx-controller-deployment.yaml to deploy the controller.

1. Deploy the execution environment

Start by deploying the execution environment from template.yml to Cloudformation.

Important

Select the region where the Aviatrix control plane is deployed in the AWS Console or AWS CLI.

Architecture Components

Terraform State S3 Bucket: An Amazon S3 bucket stores the Terraform state files. This state bucket is crucial for Terraform to track the state of resources and for ensuring idempotency in infrastructure provisioning.

Executor Lambda Function: The core of the setup is the Executor Lambda Function, which is triggered by the creation, modification, or deletion of CloudFormation resources. The Lambda function executes Terraform code against the Aviatrix Controller API. This automation enables the management of the Aviatrix Platform's resources via Terraform while using CloudFormation as the orchestration tool.

ExecutorLambdaServiceRole: This IAM role authorizes the Executor Lambda Function to interact with other AWS services. It has policies granting permissions to manage Terraform state in the S3 bucket and access secrets from the AWS Secrets Manager.

CloudWatch Logs: Utilized for logging and troubleshooting, CloudWatch Logs store the output of the Executor Lambda Function, providing insights into the execution process and facilitating error analysis. The log group is configured with a retention policy of 14 days, ensuring logs are stored for an adequate period for review and compliance.

AWS Secrets Manager: AWS Secrets Manager is employed to manage sensitive information such as the Aviatrix Controller credentials. It securely stores and retrieves database credentials, API keys, and other secrets the Lambda function needs.

Security and Compliance

Security is a paramount aspect of this architecture. The Terraform state bucket is encrypted using AES-256 encryption, and public access is blocked to protect state files. CloudWatch Logs are secured by IAM roles, allowing only authorized entities to access log data. The AWS Secrets Manager secures sensitive data, ensuring that the Lambda function can securely access necessary credentials without exposing them in the code or logs.

Operational Flow

The operational flow begins with a change in the CloudFormation stack, which triggers the Executor Lambda Function. The Lambda function runs Terraform commands to create, update, or delete resources in the Aviatrix Platform as the Terraform code specifies. The function also interacts with the S3 bucket to retrieve and update the Terraform state. Logs generated during this process are sent to CloudWatch for monitoring and troubleshooting.

2. Install the prerequisites

The following prerequisites are required to generate Cloudformation resource types from Aviatrix Terraform provider:

• Python 3
• Git
• Docker
• Terraform 1.0+
• CloudFormation CLI with Python Plugin

Example of installation on the Amazon Linux

## Clone this repository to a local directory
git clone [email protected]:nickda/aviatrix-cfn-types.git
cd ./aviatrix-cfn-types

## Install the prerequisites
sudo yum update
sudo yum install python3
sudo yum install git
sudo yum install docker
sudo service docker start
sudo usermod -a -G docker ec2-user
sudo yum install unzip
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform
sudo yum install python3-pip
pip3 install virtualenv

## Create the virtual environment and install and Cloudformation CLI and Python plugin into it
virtualenv venv
source venv/bin/activate
pip3 install cloudformation-cli
cfn --version
pip3 install cloudformation-cli cloudformation-cli-python-plugin

## Update AWS CLI to the latest version
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

## Configure AWS credentials and the region to which the Cloudformation resources will be registered
aws configure

3. Pull and Run the Lambda Python Image in Docker

docker pull public.ecr.aws/lambda/python:3.9
docker run -d -p 9000:8080 public.ecr.aws/lambda/python:3.9 app

4. Generate the Aviatrix resources and documentation

To generate resources based on the latest version of Terraform provider:

python3 generate.py

5. Submit the resources to AWS Cloudformation

Caution

By default, AWS imposes a limit of 50 custom resources per account per region. You can open a support case with AWS to increase the limit.

To submit resources one at a time:

python3 submit <resource-name>

e.g.,

python3 submit TF::Aviatrix::Account

To submit all generated resource types (in the resources folder) in bulk:

python3 submit-all.py

Note

If you'd like to submit only a subset of resource types, delete the directories with the types you won't need from the resources directory before running the submit-all.py script.

6. Configuring Aviatrix Controller IP address and credentials

To configure this resource, you must create an AWS Secrets Manager secret named aviatrix_secret.

The following arguments must be included as the key/value or JSON properties in the secret:

Argument	Description
controller_ip	The IP address of the Aviatrix controller
password	The password of the admin user

7. Deploy resources by creating a Cloudformation template

You can find an example of Controller configuration and network infrastructure deployment template in the cfn_template_examples directory.

8. (Optional) De-registering the resource types from AWS Cloudformation

If you require to deregister the resource types submitted to AWS Cloudformation you can run the following command:

python3 deregister-all.py

This will remove all custom Cloudformation resources submitted in step 5.