search

jcolemorrison / vault-on-aws

A secure HashiCorp Vault for secrets, tokens, keys, passwords, and more. Automated deployment with Terraform on AWS. Configurable options for security and scalability. Usable with any applications and services hosted anywhere.
MIT License
339 stars 60 forks source link

Consider VPC Endpoints #1

Open jhmartin opened 4 years ago

jhmartin commented 4 years ago

Consider using VPC Endpoints instead of VPC Peering for cases when Vault does not need to connect back to the source VPC or across regions. VPC Peering requires that the IP spaces be unique and exposes both sides to any potential security weaknesses in the opposite side. VPC Endpoints expose just the desired application and avoid IP conflict issues.

jcolemorrison commented 4 years ago

Oh nice, I like this idea! Let me explore adding it on the code and automation side of things. I'll post updates after I've done so. Thanks for the feedback! 😀

jcolemorrison commented 4 years ago

Just an update here - although I haven't been able to dig into setting up endpoints, I did add encryption between the load balancer and vault instances. Originally I didn't think as many folks would be interested in the VPC peering option, so I terminated TLS at the load balancer for savings and simplicity. However, the traffic and health checks between them all happen via HTTPS.

The Vault Instances' firewall only allow 8200 traffic from the load balancer, 8201 traffic from each other, and optionally SSH traffic from the Vault Bastion ONLY IF operator_mode = true. Traffic between Dynamo and KMS (and the Vault Instances) all also happen over HTTPS as well. Meaning that unless you have services / instances in your other private VPCs intentionally trying to party with the vault deployment resources, it should be good to go.

A couple of notes:

  1. I still like and will continue researching a VPC endpoint version for the project.

  2. Although IP conflicts CAN happen with VPC Peering, that's only if the AWS account has used up all of the RFC 1918 addresses available (or plans to). If that's the case, using multiple AWS accounts is the better approach. That said, the vault deployment only carves out 4096 IPs by default, and could honestly do with even less. The point being that amongst the 17 million+ IPs available to any account's VPC, most users shouldn't have to worry about the problem.

  3. The only other area of potential vulnerability, with respect to VPC peering, is the DynamoDB endpoint. Right now it is open to any thing on the private routing table. An endpoint policy can lock this down and I plan to put that in next. However, the DynamoDB table IS protected via IAM roles so it's not as if it's completely open. (edited)