Implementing Infrastructure as Code to Automate and Standardize Environment Creation
by William Wang | Senior Analyst | INTEGRITYOne Partners
Creating software solutions requires setting up working software environments robustly and efficiently. Sometimes, that set-up process must happen within minutes; examples of this may include putting together a demo or completing a technical challenge for a potential client. And sometimes, that set-up process looks very similar from project to project with only a few small changes. Integrity One Partners (IOP) uses both Amazon Web Services (AWS) and Azure for our solutions. Ideally, for each project we work on, we would like to modify only a few settings, so we are able to quickly and simply just click go to get up and running.
This is where using Infrastructure as Code (IaC) techniques and tooling can significantly speed up creation of your environments, while providing consistency of cloud deployments across your organization. At IOP, we use both Terraform and AWS CloudFormation as IaC infrastructure tools. In the details below, we will be using CloudFormation.
We can write a CloudFormation template file in JSON or YAML format, with that piece of code representing desired infrastructure. In effect, this means CloudFormation templates can be used to quickly stand-up AWS resources for a working software environment. Because the information for the infrastructure is contained in these template files, we can manage software infrastructure via organization of the template files, easily replicate infrastructure by reusing the template files, and promptly make changes to infrastructure by updating the code within the template files.
For example, we have a baseline network template which sets up a standard networking environment of a Virtual Private Cloud (VPC), subnets, gateways, route tables, and routes. The baseline network creates a 3x3 infrastructure. Within the VPC, three types of subnets are set up: public, private, and protected. Three availability zones are defined, such that there is a subnet of each type in each of the availability zones, for a total of nine subnets. The user is welcome to input whatever IP ranges they desire for the VPC and each of the subnets. The IP ranges should be provided in Classless Inter-Domain Routing (CIDR) notation and be consistent with the structure and sizing of the VPC and the subnets. Default IP ranges are provided so the user can run the template without having to input desired IP ranges.
With the VPC and subnets now defined, relevant gateways are attached to the appropriate subnets. NAT gateways are added to the private subnets to allow instances in the private subnets to connect to the internet but remain private from the Internet connecting to the instances. An Internet gateway is added to a public subnet to allow access to the internet. Route tables and routes are set up to enable the desired routing behavior with these gateways. Traffic from the private subnets is routed to their associated NAT gateways, and traffic from the public subnets is routed to the Internet gateway. References to the VPC and subnets are provided as outputs to be used in additional CloudFormation templates.
For example, the Baseline Security template builds on the Baseline Network template, adding network access control lists (NACLs) to the subnets. The user can input the name of the Baseline Network CloudFormation stack. A NACL is created for each subnet type and assigned to each of the subnets to control traffic in and out. Because different situations often call for specific security set-ups, the Baseline Security template does not meet all needs and is not intended to. Rather, it serves as a basic default set-up, and further work will extend on the Baseline Security template.
In addition to networking and security, application-based templates like a Linux Bastion template provide specific functionality. This template deploys Linux bastion hosts into the VPC, the bastion hosts providing secure access to Linux instances located in the subnets. The Linux Bastion template, like the Baseline Security template, builds off the Baseline Network. The user can modify the allowed CIDR block for access to the bastion hosts, the Amazon Machine Image (AMI) for the instances, and the instance type. Using the parameters the user provides, the template creates the bastion instances with the appropriate launch configuration, and a security group enabling SSH access to the bastion instances from the provided CIDR block only.
There exist many more use cases when it comes to implementing AWS resources. Container Management Services and Continuous integration/Continuous delivery (CI/CD) are two examples of application topics for which we can build CloudFormation templates. Building templates for Container Management Services involves setting up Elastic Container Service (ECS) resources or Elastic Kubernetes Service (EKS) resources to create the desired containerized software applications. Templates for CI/CD involve CodePipline, CodeCommit, CodeDeploy, and CodeBuild resources to set up the software pipeline for building, testing, and deploying code.
At IOP, we maintain the highest level of security in everything we do. Our templates apply least privilege access, limiting network access and permissions to the lowest permissions possible per requirements. Furthermore, our templates implement best practices for networking security, including limiting system access via security groups, limiting network access via NACLs, and isolating systems in specific subnets for public, private, and protected. Finally, we create our templates to be highly parameterized to enable a flexible foundation that can be utilized in a variety of environments without requiring changes.
Our CloudFormation templates live on a GitHub repository for team members to download and use. Having a suite of IaC templates gives team members the ability to choose the set of templates that most align to their projects, update them for any project specifics and go. This greatly increases the speed we can get a new project up and going, while providing the ability to recreate the environment to support additional development, test, and training environments and better prepare us for production deployments. As our needs change, and as technology inevitably evolves, we modify and update the templates to ensure they remain the most efficient and secure method to set up and operate new infrastructure.
Originally published at https://ionep.com
