AWS Elastic Container Registry

AWS S3

AWS Key Management Service

AWS Elastic Container Serivce

In June 2021, I released Free-tier Vault with Cloud Run, which allow you to deploy HashiCorp Vault on Google Cloud full managed serverless container platform, Cloud Run. GCP is my primary (and favorite) cloud provider, but I thought I'd try to make a similar deployment equivalent on Azure's Container Instances and AWS' Fargate. I figured this would allow me to learn a bit more about Azure and AWS' offerings.

HashiCorp's products makes this possible by offering binaries for all sorts of architectures and operating systems, so whether you're on a Mac or Windows or Raspberry Pi, there's a binary for you!

NOTE: I am once again building my own Vault Docker image because I wanted to learn how the IAM piece works with AWS and also using their managed Elastic Container Registry. You can just as easily use the HashiCorp provided Docker image when deploying your ECS.

This repo contains Terraform code that will deploy the required underlying infrastructure (ECR, S3, KMS for auto-unseal, ECS Fargate for the app deployment), but the user will have to perform some tasks via the AWS CLI and ECS CLI. The details of those command can be found here

ECS Fargate, to me, is a bit weird. It's not what I would consider truly serverless as you still have to reference a VPC and its subnets. The unintended "pro" of this is you can apply security groups to it, which is not something you can with GCP or Azure without attaching a load balancer.

This will serve as the storage backend for Vault.

Used for auto-unseal

Where the Vault binary will be run from.

CodeBuild cannot reach out to the internet to download from GitHub repo unless I have a NAT provisioned otherwise I get a DOWNLOAD_SOURCE Failed Error. This would require me to provision a VPC with 2-3 subnets and a NAT for each which would inflate the costs of this serverless Vault deployment, hence I will be leaving this part out (for now...?).

Currently I am not encrypting the IAM key during resource creation, meaning that both the access key id and secret access key are stored in plain text in the Terraform state file. I am aware this is insecure and not best practices but will be something I will look to remediate at a later time. Optionally, you can leave out the ECS Task Definition resource and create it via AWS CLI (manual steps outlined here). However, because the credentials are passed in as part of environment variables to the task definition, it will show up in task details and you probably don't want that. A better way would probably be using a specific IAM role for the container instance, but I haven't really dug deep into that yet and will be in a later release as I make incremental improvements to this repo.