Skip to content

Latest commit

 

History

History
127 lines (83 loc) · 6.78 KB

README.md

File metadata and controls

127 lines (83 loc) · 6.78 KB
Raw

Deploying Covid Shield on Amazon Web Services (AWS)

⚠️ This is not a fully featured production environment and aims to provide an accessible overview of the service.

This document describes how to deploy and operate a reference implementation of the Covid Shield web portal, along with the diagnosis key retrieval and submission services on AWS.

There should be an illustration of the Covid Shield infrastructure deployed on AWS right here

At a glance, health care professionals (on the left) interact with a web portal, and mobile app users (on the right) interact with the diagnosis key retrieval and submission services.

IT Service Requirements

Service AWS product offering
Serverless compute Fargate
Container registry Elastic Container Registry
Domain name services Route 53
TLS certificates Certificate Manager
Load balancing Elastic Load Balancing
Content delivery network CloudFront
Web application firewall WAF

Deploying Covid Shield 🛡️

While this infrastructure may be deployed in a number of different ways, this document demonstrates a deploy using a small series of command line operations to generate credentials, and a CI/CD pipeline using GitHub Actions, Docker, and Terraform.

Prerequisites

Optional TODO: make a quick playbook doc to see if the containers are up or down? or pivot to the ui?

  • ecs-cli installed and available in your path

Deploying to AWS with Terraform

The credentials for the AWS Terraform provider are expected to be provided through the standard AWS credential environment variables.

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY_ID

If it's not already done, and before applying. You will need to enable the new ARN format to propagate tags to containers.

aws ecs put-account-setting-default --name serviceLongArnFormat --value enabled
aws ecs put-account-setting-default --name taskLongArnFormat --value enabled
aws ecs put-account-setting-default --name containerInstanceLongArnFormat --value enabled

All Terraform variables are defined in config/terraform/aws/variables.tf & their values are set in config/terraform/aws/variables.auto.tfvars. There are seven secret variables that should be set through the following environment variables as to not commit plain text secrets to version control.

  • TF_VAR_ecs_task_key_retrieval_env_ecdsa_key
  • TF_VAR_ecs_task_key_retrieval_env_hmac_key
  • TF_VAR_ecs_task_key_submission_env_key_claim_token
  • TF_VAR_rds_backend_db_password
  • TF_VAR_cloudfront_custom_header
  • TF_VAR_environment
  • TF_VAR_new_key_claim_allow_list (use ["0.0.0.0/1", "128.0.0.0/1"] for any)

If you are using Terraform in Github actions the above can be set as Github secrets, and set as environment variables in your YAML file (see .github/workflows/terraform.yml).

There is an optional Terraform variable that can be set to control which container to deploy. It should match a container tag that both Key Retrieval & Key Submission share. By default Terraform will deploy the latest commit on the master branch.

  • TF_VAR_github_sha

To run manually:

  1. Go to the AWS Terraform directory - cd config/terraform/aws
  2. Run

TF_VAR_ecs_task_key_retrieval_env_ecdsa_key="" TF_VAR_ecs_task_key_retrieval_env_hmac_key="" TF_VAR_ecs_task_key_submission_env_key_claim_token="" TF_VAR_rds_backend_db_password="" AWS_ACCESS_KEY_ID="" AWS_SECRET_ACCESS_KEY="" terraform [init|plan|apply]

Building and releasing applications with GitHub and Docker 🐳

This section will demonstrate the following:

Getting started with GitHub Actions

According to GitHub, Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

We've chosen to configure a number of Actions to make the infrastructure go brrrr 🤖, here they are:

  1. [ci](to test a thing), for container vulnerability scanning
  2. [ci](to scan a thing), for __
  3. [ci](docker build), for __
  4. [ci](docker push), for __
  5. [cd](to ecs), for __

Action #1: test a thing

Action #2: scan a thing

Action #3: build a thing

Action #4: push a thing

Action #5: deploy a thing

Integrating dependency management with Dependabot

According to GitHub (because they own it), Dependabot creates pull requests to keep your dependencies secure and up-to-date.

Configuring Dependabot requires one or two things:

  1. Sign up and grant Dependabot access to your repositories
  2. You can configure the repository in the UI after signing up. Alternatively, you may specify a Dependabot config file in your repository at .dependabot/config.yml

Here is the Dependabot configuration we chose for the Portal:

version: 1
update_configs:
- package_manager: "ruby:bundler"
  directory: "/"
  update_schedule: "weekly"
- package_manager: "javascript"
  directory: "/"
  update_schedule: "weekly"

This configuration schedules the 🤖 to check for updates every week for both the Bundler and Yarn packages deployed with this application. Feel free to run this configurations through the configuration validator to attest that it is valid.