New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: credstash vs hashicorp vault #60

Closed
DanyC97 opened this Issue Jan 3, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@DanyC97

DanyC97 commented Jan 3, 2016

Hi,

I love your project, very tidy/ clean/ simple !
However i'd appreciate your thoughts/ rational for creating credstash rather than using hashicorp vault?

@alex-luminal

This comment has been minimized.

Contributor

alex-luminal commented Jan 4, 2016

Hello @DanyC97. The simple explanation is that I wrote credstash before hashicorp released vault :) I wrote the first super-hacky version in December 2014, right after AWS launched KMS and I wanted a simple utility that would use KMS to manage secrets used in shell scripts and bits of our CI/CD system. We used credstash internally (at Fugue) for several months before we Apache2'd it. A few days after we opened up credstash (https://blog.fugue.co/2015-04-21-aws-kms-secrets.html), hashicorp launched vault.

Vault is really neat and they do some cool things (dynamic secret generation, key-splitting to protect master keys, etc.), but there are still some reasons why you might pick credstash over vault:

  • Nothing to run. If you want to run vault, you need to run the secret storage backend (consul or some other datastore), you need to run the vault server itself, etc. With credstash, there's nothing to run. all of the data and key storage is handled by AWS services
  • lower cost for a small number of secrets. If you just need to store a small handful of secrets, you can easilly fit the credstash DDB table in the free tier, and pay ~$1 per month for KMS. So you get good secret management for about a buck a month.
  • Simple operations. Similar to "nothing to run", you dont need to worry about getting a quorum of admins together to unseal your master keys, dont need to worry about monitoring, runbooks for when the secret service goes down, etc. It does expose you to risk of AWS outages, but if you're running on AWS, you have that anyway

That said, if you want to do master key splitting, are not running on AWS, care about things like dynamic secret generation, have a trust boundary that's smaller than an instance, or want to use something other than AWS creds for AuthN/AuthZ, then vault may be a better choice for you.

Hope that answers your question!

@alex-luminal

This comment has been minimized.

Contributor

alex-luminal commented Jan 4, 2016

I'm going to close this, but feel free to re-open it if you have other questions

@DanyC97

This comment has been minimized.

DanyC97 commented Jan 4, 2016

@alex-luminal much thanks!!
It does perfect sense what you wrote and i can see it an easy fit for using it instead of using data bag with chef.

Keep up the good work and don't give up on improving it. I'll try to integrate it with Saltstack and so will let you know once is ready.

Best,
Dani

@anapsix

This comment has been minimized.

anapsix commented Feb 9, 2017

no infrastructure to speak of, no servers to maintain, patch, monitor.
DynamoDB + KMS, with IAM roles for auth = simplicity, availability = winning

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment