> Use local environment variables, when feasible
Hmm no, environments vars are very convenient but leak like crazy easily.
Best practices for managing and storing secrets like API keys and credentials
21–30 of 36 posts
Re: Best practices for managing and storing secrets like API keys and credentials
#22rule #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.
Re: Best practices for managing and storing secrets like API keys and credentials
#23> Using wildcard commands like git add *or git add . can easily capture files that should not enter a git repository No they cant, because of .gitignore
Because mistakes happen and adding a secret into path that is not hit by gitignore can happen. At least if you manually add you will have to consciously add the path that leaks secret. It is a defense in depth. Ideally first layer protects you, but this way you have another strong layer.
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.
Re: Best practices for managing and storing secrets like API keys and credentials
#24the current solutions for secrets management just seem to pass the buck, this problem is far from solved. Where you going to store your secrets that spin up your k8s environment? It eventually comes down to protecting your PGP key I think. Where do you store the secret for your admin account to AWS? Or to your domain name provider? Or bank account? 1password? I suppose once your core infrastructure is up you just gen…
I think the only really credible answer to this is "vault unseal." The first phase of availability zone turnup is assembling your quorum.
Re: Best practices for managing and storing secrets like API keys and credentials
#25Great 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…
HA is there in OSS now with their raft store.
I think you could’ve also done in the past if you used consul for vault’s storage.
Re: Best practices for managing and storing secrets like API keys and credentials
#26rule #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.
Re: Best practices for managing and storing secrets like API keys and credentials
#27Earlier quoted context omitted.
Because mistakes happen and adding a secret into path that is not hit by gitignore can happen. At least if you manually add you will have to consciously add the path that leaks secret. It is a defense in depth. Ideally first layer protects you, but this way you have another strong layer.
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: This is an entirely serious question and I am hoping for an answer. I promise I'm not trying to antagonise anyone. I just see so many people reaching for "add ." instead of "add -i".
Re: Best practices for managing and storing secrets like API keys and credentials
#28> Use local environment variables, when feasible Hmm no, environments vars are very convenient but leak like crazy easily.
Citation, please.
No situation readily come to mind where an attacker could gain access to env vars but would not also have access to any other means of persistence.
Re: Best practices for managing and storing secrets like API keys and credentials
#29Great 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…
HA is there in OSS now with their raft store. I think you could’ve also done in the past if you used consul for vault’s storage.
HA has always been in OSS
Re: Best practices for managing and storing secrets like API keys and credentials
#30Great article