What does HackerNews think of credstash?

A little utility for managing credentials in the cloud

Language: Python

Ask HN: Secure and simple way for secret/credential management in a startup? | Mar 2023
Hello,

At my current gig we're using doppler[^1] (no affiliation) for application secrets. We're using doppler with their kubernetes operator which supports auto-rotation on secrets. Secrets are set as "env variables". So far, doppler has not suffer big outages or we did not notice, because the operator will keep working even if their API is down - of course you won't get updates. Access control could be more _fine grained_ and they added secret auto-rotation option recently[^2]. We don't use that yet.

I've been a happy 1Password user (no affiliation) and we use it company wide to share user secrets. 1Password support CI/CD integration IIRC, so in theory should cover most use cases.

If you can pay for AWS Vault, the terraform integration comes out of the box. However if you're a small team running vault might be a daunting task and you're inserting another SPoF.

There are many open source application secrets tools that you could check out though. In the past I had great experience with credstash[^3]. Credstash is a really simple and secure open source solution that is based on AWS KMS, IAM and DynamoDB. Costs pennies to run for medium size deployments. Once you setup and document the way to use it, it's really easy. The downside is that as a tool is pretty _raw_ you have to build things like "secret generators", etc. But combined with a slack bot can be a really powerful, secure, cost-effective self-hosted solution that doesn't require maintenance (as opposed to solutions like Vault).

If you have specific questions about any of the above tools feel free to drop an email. I'll happy to answer questions.

[^1]: https://www.doppler.com/

[^2]: Auto-rotation is complicated because you need to integrate the auto-rotation with external tools yourself most of the times. There are Hashi-Vault modules for SQL DBs but not for Mailgun or CloudFlare for example.

[^3]: https://github.com/fugue/credstash

How to manage any kind of secret with AWS Secrets Manager | Jul 2018
This write-up is solid - but man, this product looks questionable. 40 cents per secret per month? With Credstash[0] or a moral equivalent[1] you pay a buck for a KMS key and microcents for the data storage.

RDS rotation is...fine, I guess, if you have an auditor who really wants that and can't write a scheduled job for the task (I've been using one with credstash so long it's just an automatic part of a new environment), but it's got me skeptical.

Something AWS could do, and I'd be very interested in, is a hosted moral equivalent to Vault. Give me a daemon or something to run on an instance, allow me to IAM-gate temporary SSH credentials (and chuck it in CloudTrail) and temporary SQL databases, and that I'd pay for 'cause I really don't want to deal with Vault or HashiCorp. But AWS Secrets Manager, by itself, doesn't really present a good reason-for-being to me.

[0] - https://github.com/fugue/credstash

[1] - https://github.com/codahale/sneaker

Ask HN: Tools for Managing Secret in Production Scale? | Apr 2018
https://github.com/fugue/credstash

https://aws.amazon.com/secrets-manager/

Travis CI Security Advisory: Secured Environment Variables | May 2017
Expand Context ↕
Not applicable for y'all, but for our AWS people, I'll cape up for Credstash[1] (or its moral equivalent, Sneaker[2], but I prefer the use of a Dynamo table to S3 for this). Uses IAM to ensure secret access and offers revisioning. Plus it's super easy to work with. My normal stack, using my own Auster[3] for orchestration, uses an offline, file-based secrets store (usually an encrypted USB key in production) for stuff like database root passwords that don't need to be online, then push database passwords into Credstash with encryption contexts (the KMS thing that makes IAM effective for this). My Chef cookbooks happily slurp in credstashed secrets via rcredstash, now that the PR to make it work with parameterized KMS keys has hit, and provisioning is very straightforward. (There are a lot of proper nouns in this paragraph, but the nice thing is that each component handles its own business and so there aren't many vertical concerns.)

CI secret access isn't a thing in the systems I develop (unit tests don't need them, integration tests get a spun-up environment that provisions its own secrets), but you could provide access with a bog-standard token machine.

[1] https://github.com/fugue/credstash

[2] https://github.com/codahale/sneaker

[3] https://github.com/eropple/auster
New for AWS Lambda – Environment Variables and Serverless Application Model | Nov 2016
I started with a manually-packaged Python function and credstash [1] to store credentials for non-AWS services. It gets invoked nightly by CloudWatch and has been bulletproof for months. I recently built a microservice [2] for Election Day with Flask and deployed it behind API Gateway with Zappa [3]. Lambda isn't for every use case, but for those it is, I'm bullish.

[1] https://github.com/fugue/credstash

[2] https://topics.arlingtonva.us/2016/11/voter-registration-sea...

[3] https://www.zappa.io/

Secret Management with Vault | Oct 2016
Expand Context ↕
We initially looked around, and here are a few alternatives:

    - 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.
Biscuit: a multi-region key value store for your AWS infrastructure secrets | Jul 2016
I prefer credstash (https://github.com/fugue/credstash) which uses KMS and stores encrypted values in dynamodb. It has built in ansible support via lookups too!
Our nightmare on Amazon ECS | Jul 2016
Expand Context ↕
Use kms and dynamodb with key enveloping, or this tool: https://github.com/fugue/credstash

Don't initialize into env vars and don't store in repos, even private ones.
Our nightmare on Amazon ECS | Jul 2016
Probably want to use a secret management tool and just not initialize into environment variables...

https://github.com/fugue/credstash

Git-secret – store private data in a Git repo | May 2016
Expand Context ↕
It is helpful to store configuration with code, but you don't have to include secret values in your code. It's much better to use a purpose built service like credstash[0] to store secret values while you keep the name of the secret and (possibly) version in a repo with your code.

[0] https://github.com/fugue/credstash
Git-secret – store private data in a Git repo | May 2016
Agree, also check out credstash[0], a very good and secure solution if you are running on AWS. Credstash is an small utility that encrypt with KMS and store the ciphertext of the datakey and secret on Dynamodb.

I configure my application roles to be able to decrypt with the master key and I restrict what ciphertext they can read from Dynamodb.

[0] https://github.com/fugue/credstash

Confidant: an open-source secret management service | Nov 2015
Another alternative developed for AWS deployments, written in Python and uses KMS: Credstash https://github.com/fugue/credstash
Confidant: an open-source secret management service | Nov 2015
Expand Context ↕
We wrote Confidant in the beginning of 2015, so it's not a reinvention of sneaker. That said, sneaker is very similar in design, as is credstash: https://github.com/fugue/credstash

Both of those are really great projects and I recommend them if they fit your use-case.

One of the reasons we originally avoided S3 was because it can occasionally be very eventually consistent, which we wanted to avoid. We also wanted to avoid fanning out secrets to services when the secret needed to be shared between multiple services.

We also wanted to have a UI that was simple and easy to use for everyone.