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(blog.gitguardian.com) |
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.
It uses PBKDF2 with 10,000 iterations if anyone else was wondering.
The code is clean, kudos.
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?
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. :-) )
For example you can use sops (https://github.com/mozilla/sops) to store encrypted secrets in Git, using AWS/GCP KMS to encrypt/decrypt them (or encrypt/decrypt the encryption key), and have infrastructure automation that gets the secrets from sops and exposes them to applications as environment variables.
It uses gnome-keyring (linux) or keychain (mac).
Unfortunately you need to install it from source as it's not popular, or known at all, but how about we give it some love and push to include it in package repositories (debian, arch, etc)?
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
KMS isn't a secrets management system. It's for managing encryption keys, though it can be used in tandem with AWS's Parameter Store, which can be used as a secret management system. As a matter of fact, Task Definitions in ECS can pull those secrets out as environment variables in your containers, which IMO is pretty elegant.
Shamless ad: If you guys are looking for a free and easy to use secrets manager with powerful features that work on every stack, I would recommend Doppler (YC W19). For transparency, I am the CEO.
Doppler is a cloud-hosted secrets manager designed to win the heart of the developer while meeting all the requirements of your security team. It works great in local development and production, can be nearly 100% automated, and has built-in versioning, reusable configs, audit logs, SSO, granular access controls, can automatically sync with your infra provider's secrets store (ex: Heroku Config Vars). It also has high availability features built into every part of our stack (from our open-source CLI creating encrypting fallback files to our servers running on multiple infrastructures).
Feel free to create a free account (no cc required) at https://doppler.com
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.
Secrets that are needed in server or development contexts are a lot trickier. There's a fundamental tension between making them widely and easily available (which makes development and ops easier), and restricting access (which is necessary for security). You'll also probably have multiple versions of the same secrets in different environments, have teams of developers that all need to stay in sync, etc. etc. Password management, as important as it is, has fewer moving pieces.
You should also require MFA to use your admin credentials either programmatically or on the web.
With AWS, you can even use an IAM role to connect to Mysql and Postgres so you don’t need to store a password for database access. You can use the SDK to generate a temporary password to the database.
No they cant, because of .gitignore
It is a defense in depth. Ideally first layer protects you, but this way you have another strong layer.
rule #2: its not only secrets management, the whole stack should go through security hardening and regular security review.
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)
Hmm no, environments vars are very convenient but leak like crazy easily.
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.
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
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".
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?