This repository is an example of best-practice deployment for the General Services Administration. More specifically, it demonstrates how to do configuration and deployment for an application that writes to disk. See the DevSecOps Guide for more information.

The example application being deployed is WordPress. With a default configuration, WordPress will save uploads, themes, and plugins to the local disk. This means that it violates the Twelve-Factor App Processes rule. While WordPress can be configured to save files elsewhere (example), it is being used here as a stand-in for pieces of (legacy?) software that don't have that option.

This is just an example implementation of the GSA DevSecOps principles/component - the repository should still be useful to you, even if you aren't using WordPress, or your architecture isn't exactly the same.

A mgmt ("management") VPC is created.

WordPress runs on a hardened Ubuntu 16.04 EC2 instance in a public subnet, and connects to a MySQL RDS instance in a private subnet. All of this is isolated in an env ("environment") VPC, which is set up with a VPN to a central Transit VPC.

Squid runs on a hardened Ubuntu 16.04 EC2 instance in a public subnet and sits behind a Network Load Balancer and acts an Egress Proxy for servers in the env ("environment") VPC.

Currently, both the management and environment VPCs will be deployed in the same account, but we are moving to having them separate.

• terraform/ - Terraform code for setting up the infrastructure at the Amazon Web Services (AWS) level, for a management account (mgmt/) and application environment(s) (env/)
• packer.json - Packer template for creating an Amazon Machine Image (AMI)
• ansible/ - Ansible code for installing and configuring WordPress and Squid on two EC2 instances, which are made into AMIs via Packer.

1. Set up the AWS CLI.

   1. Install
   2. Configure

2. Install additional dependencies:

   • Ansible
   • Packer
   • Terraform

3. Install Ansible dependencies.

   ansible-galaxy install -p ansible/roles -r ansible/requirements.yml

4. Specify a region (options).

   export AWS_DEFAULT_REGION=...

1. Create the base AMIs, if they aren't shared with your AWS account already.

2. Set up the Terraform backend.

   cd terraform/bootstrap
   terraform init
   terraform apply

1. Create the Terraform variables file.

   cd ../mgmt
   cp terraform.tfvars.example terraform.tfvars

2. Fill out terraform.tfvars. This file SHOULD NOT be checked into source control.

3. Set up Terraform.

   terraform init "-backend-config=bucket=$(cd ../bootstrap && terraform output bucket)"

4. Create the management VPC.

   terraform apply

1. Create an access key for the deployer user.
2. Set up CircleCI for the project.

   • Specify environment variables:

     • The required AWS configuration
     • TF_ENV_BUCKET - get via terraform output env_backend_bucket
     • TF_VAR_db_pass
     • TF_VAR_general_availability_endpoint
     • TF_VAR_egress_proxy_port - default is 3128
     • TF_VAR_egress_proxy_acls - default is [] see Squid Docs

   • Generate a deployer key, and add it under the project settings.

     ssh-keygen -t rsa -b 4096 -f id_rsa_circleci -C "[email protected]" -N ""
     cat id_rsa_circleci | pbcopy
     
     # save as private key in CircleCI
     
     rm id_rsa_circleci*

   • The build will bootstrap the environment.

3. Visit the site, which is the url output from Terraform at the end of the CircleCI run, to complete WordPress setup.

Note that if the public IP address changes after you set up the site initially, you will need to change the site URL in WordPress.

To SSH into the running WordPress instance:

ssh $(terraform output ssh_user)@$(terraform output public_ip)

Part of the build runs in a custom container. To update it:

docker --version
# make sure you have v17.05+

docker build --pull -t 18fgsa/devsecops-builder:alpine - < Dockerfile
docker push 18fgsa/devsecops-builder:alpine

Once fully deployed, do the following to delete the project:

1. Temporarily remove all the lifecycle blocks from under terraform/.

   • This is necessary because Terraform, as of v0.11.1, doesn't allow these blocks to contain interpolation.

2. Destroy the env.

   cd terraform/env
   terraform destroy

3. Destroy mgmt.

   cd ../mgmt
   terraform destroy

4. Destroy bootstrap.

   cd ../bootstrap
   terraform destroy