Best practices for managing and storing secrets like API keys and credentials
blog.gitguardian.com
Best practices for managing and storing secrets like API keys and credentials
1–10 of 36 posts
Re: Best practices for managing and storing secrets like API keys and credentials
#2Great 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 integrate legacy code with Vault.
3) System-level access must be protected carefully: Well, this is always true, but Vault gives you more options than many others here as well: based on risk assessments, you can choose to limit the secrets you issue, particularly when you're talking about system-level access. You can have very short TTLs, one-time-use wrappers that limit the exposure of said secrets, etc.
(I don't mean to sound like a shill, BTW. It's just that these points easily jumped to mind, having just certified as a Vault Associate. YMMV. :-) )
Re: Best practices for managing and storing secrets like API keys and credentials
#3> 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
Re: Best practices for managing and storing secrets like API keys and credentials
#4> 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.
Re: Best practices for managing and storing secrets like API keys and credentials
#5We built ironhide https://github.com/IronCoreLabs/ironhide to help developers share secrets with each other and with CI.
Re: Best practices for managing and storing secrets like API keys and credentials
#6This post is spot on! For anyone looking for a light-weight solution based on environment variables/12-factor, check out EnvKey (I'm the founder) - https://www.envkey.com
It's cloud-hosted, but uses client-side end-to-end encryption to avoid trusting our servers (all clients are open source). The focus is on seamless integration (generally ~1 minute for a new project), intuitive ux, and platform-agnosticism.
We're also close to launching a v2 that can run on your own infrastructure with HA and offers a lot more power and flexibility--version control, audit logs, a CLI for automation, 'config blocks' that can be re-used across apps and services, managing local environments, SSO, teams, and event hooks are some of the highlights.
Also, we're hiring (remote in the USA). Our stack is TypeScript/Go/Polyglot. Please get in touch if you're interested in this stuff! dane@envkey.com
Re: Best practices for managing and storing secrets like API keys and credentials
#7Shameless plug for a k8s oriented tool that fits this space:
Re: Best practices for managing and storing secrets like API keys and credentials
#8> 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
I think the idea is "defense in depth" - but you are correct - if you use env vars/vaults, and a proper .gitignore, this isn't an issue.
Re: Best practices for managing and storing secrets like API keys and credentials
#9the 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 generate random passwords and store them in k8s for access when bringing up your infrastructure.
Re: Best practices for managing and storing secrets like API keys and credentials
#10This 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 you are working for an employer where you don't even get to have a say in the infra)
At Plyint(https://plyint.com), we actually use it to manage team level secrets through Keybase. To make this easier we wrote an extension encpass-keybase.sh(https://github.com/plyint/encpass.sh/blob/master/extensions/...), which uses Keybase's keys, encryption, and git repos.