- Azure Key Vault: https://azure.microsoft.com/en-us/services/key-vault/
- Blackbox: https://github.com/StackExchange/blackbox
- CredStash: https://github.com/fugue/credstash
- Lyft Confydant: https://github.com/lyft/confidant
- Trousseau: https://github.com/oleiade/trousseau
- Sneaker: https://github.com/codahale/sneaker
Some of these didn't exist when we were first investigating proper secret management, while others didn't fit as well with our deployment strategy. We're using what works when it makes sense - Blackbox is used in some repos, for instance - but I'll be sure the next time we have an internal doc like this that we cover why we didn't choose a different set of tools.One thing we liked about Vault is that it built upon our usage of Consul and the http interface for Vault meant it was simple to plug into how we build and deploy services. While I'm sure some of these other tools would have had as good workflows, our experience in administrating Consul made it easier for us to have confidence in Vault.
A big reason was that Vault’s AWS authentication backend is not based on AWS infrastructure like IAM/KMS, but uses a somewhat backhanded method (https://www.vaultproject.io/docs/auth/aws-ec2.html) to establish verify an EC2 instance. We use ECS, and it doesn't play well with it - see https://github.com/hashicorp/vault/issues/1298
Instead, we would have had to fall back to the App ID method, which requires separate configuration, and is “Trust On First Use” so doesn’t offer as strong of security guarantees in my opinion.
Also, the only Hashicorp supported-backends are file (non-HA) and Consul.
If you're all-AWS, I'd recommend checking out Confidant/Knox (run as a separate service) or Credstash/Biscuit (run directly against AWS infra).
Integration with a CI bot is another consideration.