Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best practices for managing and storing secrets like API keys and credentials

blog.gitguardian.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Best practices for managing and storing secrets like API keys and credentials

#31

Post by closeparen »

CuriousCosmic wrote: post #27
closeparen wrote: post #23

Earlier quoted context omitted.

Giving up "git add ." is a steep price. I prefer to store my secrets outside the working copy. Then when I cd into the working copy, direnv sets environment variables either pointing to or catting the files from my home directory. This works beautifully with Ansible Vault.

I'm curious why people use "git add ."? I don't see the convenience over "git add -i" and quickly reading through the items to add. Realistically if you have a reasonable git workflow any add operation should only have a handful of files that you can quickly scan through to make sure nothing fishy is present and at most interactive mode adds a few seconds to the add process for you to read through everything. Note: T…

Keeping a file untracked is never what I want. Either it goes in the repo or it goes in .gitignore. My gitignores are usually comprehensive, and when they're not I'll catch it in my self-review of the PR.

Re: Best practices for managing and storing secrets like API keys and credentials

#32

Post by jlj7 »

Znafon wrote: post #17
jlj7 wrote: post #2

Great article. I would point out, though, that the disadvantages listed against Secrets as a Service need not apply to Hashicorp's Vault: 1) Single point of failure: Vault Enterprise offers high availability solutions that should be able to mitigate much of this (at a cost, of course). 2) Codebase must be changed: Vault (and Consul) really shine here: Consul Template -- and Envconsul -- can be used to seamlessly inte…

Regarding 1, I don't think you need Enterprise to have HA, I'm pretty sure it comes with Vault OSS. You may be thinking about Vault Disaster Recovery which makes one cluster fail to another one, but HA is in OSS.

I was thinking of on-call support being a key part of the overall concept of HA, but, yes, good point: much of this risk can be mitigated, even with OSS.

Re: Best practices for managing and storing secrets like API keys and credentials

#33

Post by CuriousCosmic »

closeparen wrote: post #31
CuriousCosmic wrote: post #27

Earlier quoted context omitted.

I'm curious why people use "git add ."? I don't see the convenience over "git add -i" and quickly reading through the items to add. Realistically if you have a reasonable git workflow any add operation should only have a handful of files that you can quickly scan through to make sure nothing fishy is present and at most interactive mode adds a few seconds to the add process for you to read through everything. Note: T…

Keeping a file untracked is never what I want. Either it goes in the repo or it goes in .gitignore. My gitignores are usually comprehensive, and when they're not I'll catch it in my self-review of the PR.

That's fair but isn't it more work to go back and have to rebase your commits to remove something that accidentally got skipped in your .gitignore?

I say this because I am also a firm believer of if it shouldn't be committed it should be in the .gitignore but I've only ever been burned by that when either myself or others weren't using interactive add.

Basically, isn't it easier to fix a .gitignore at commit time than at PR time?

Re: Best practices for managing and storing secrets like API keys and credentials

#34

Post by somurzakov »

pmontra wrote: post #26
somurzakov wrote: post #22

rule #1: never give developers production secrets. That way they wont be able to misuse them or push them to the repo. From my experience devs only care whether their software works, security is often an afterthought. rule #2: its not only secrets management, the whole stack should go through security hardening and regular security review.

Rule #1 is really important. Unfortunately many small companies and most startups only have developers and no separate operations department. The best those developers can do is keeping secrets out of git, slack and email. I'm using git secret for a project of a customer with one internal developer and about five external consultants.

if that's the case, then only a team lead / most senior dev should have prod secrets. and I would prefer to be very low tech in terms of secrets management.

definitely not passing secrets in ENV (cause any process can access ENV and exfiltrate) or as command line argument (cause they will be logged as all tty commands are)

Re: Best practices for managing and storing secrets like API keys and credentials

#35

Post by Mandatum »

kohtatsu wrote: post #12
ahnick wrote: post #10

This is pretty much why we created encpass.sh( https://github.com/plyint/encpass.sh ). It's just a single POSIX compliant shell script whose only real requirement is having OpenSSL installed. Sometimes when you are hacking on a shell script or you have some configuration management pieces you just need a simple way to store and access secrets locally without having to invest in a lot of infrastructure. (Especially if…

https://github.com/plyint/encpass.sh/blob/93d42340/encpass.s... It uses PBKDF2 with 10,000 iterations if anyone else was wondering. The code is clean, kudos.

Is there an easy way to tell the version of an encpass.sh if all you have is the script?

Say I was checking my encpass.sh files on a bunch of different nodes and wanted to make sure they were all based on the current master version - would I have to sha256 them and compare?

Re: Best practices for managing and storing secrets like API keys and credentials

#36

Post by ahnick »

Mandatum wrote: post #35
kohtatsu wrote: post #12

Earlier quoted context omitted.

https://github.com/plyint/encpass.sh/blob/93d42340/encpass.s... It uses PBKDF2 with 10,000 iterations if anyone else was wondering. The code is clean, kudos.

Is there an easy way to tell the version of an encpass.sh if all you have is the script? Say I was checking my encpass.sh files on a bunch of different nodes and wanted to make sure they were all based on the current master version - would I have to sha256 them and compare?

Yes, just compute the sha256 checksums and compare. I had been meaning to add a version command to encpass.sh for a while now and just hadn't made time for it. Your comment was the impetus I needed, so I've gone ahead and added support for computing the sha256 checksums of encpass.sh and any extension and also displaying the tag version.

I've cut a new release for the version command, v4.1.0. See the release notes here for additional details -> https://github.com/plyint/encpass.sh/releases/tag/v4.1.0

Post reply on HN