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 you are working for an employer where you don't even get to have a say in the infra)
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. :-) )
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.
The "Store secrets safely" section seems to propose three alternative solutions: store secrets encrypted in Git, expose secrets to applications with environment variables, and encrypt secrets with KMS. But those are solutions to different problems. You can use all three.
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.
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)?
https://github.com/mozilla/sops is quite good to store encrypted secrets. Because the decryption key is stored in a KMS the secret access can be revoked any time.
This 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! [email protected]
> Secrets management systems such as Hashicorp Vault or AWS Key Management Service
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.
This post is great! I would also add using the built-in secrets store your infra provider has in staging and production. For example, Heroku has config vars.
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).
the 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.
For passwords, you can use 1password or another password manager--that's pretty much solved at this point.
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.
For AWS, locally, you store your secrets in your user directory which shouldn’t be anywhere near your hit repository. All of the SDKs will automatically find your keys there. When you run your code on either EC2, Lambda, or ECS (Docker), the SDK will automatically use the keys based on the attached role.
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.
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.
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.
[+] [-] ahnick|5 years ago|reply
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.
[+] [-] kohtatsu|5 years ago|reply
It uses PBKDF2 with 10,000 iterations if anyone else was wondering.
The code is clean, kudos.
[+] [-] jlj7|5 years ago|reply
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. :-) )
[+] [-] Znafon|5 years ago|reply
[+] [-] atonse|5 years ago|reply
I think you could’ve also done in the past if you used consul for vault’s storage.
[+] [-] antoncohen|5 years ago|reply
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.
[+] [-] _odey|5 years ago|reply
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)?
[+] [-] zimbatm|5 years ago|reply
[+] [-] danenania|5 years ago|reply
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! [email protected]
[+] [-] bdcravens|5 years ago|reply
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.
[+] [-] philipov|5 years ago|reply
[+] [-] bvallelunga|5 years ago|reply
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
[+] [-] clintfred|5 years ago|reply
[+] [-] ithkuil|5 years ago|reply
https://github.com/bitnami-labs/sealed-secrets
[+] [-] waynesonfire|5 years ago|reply
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.
[+] [-] danenania|5 years ago|reply
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.
[+] [-] scarface74|5 years ago|reply
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.
[+] [-] closeparen|5 years ago|reply
[+] [-] rossmohax|5 years ago|reply
No they cant, because of .gitignore
[+] [-] ivalm|5 years ago|reply
It is a defense in depth. Ideally first layer protects you, but this way you have another strong layer.
[+] [-] unethical_ban|5 years ago|reply
[+] [-] somurzakov|5 years ago|reply
rule #2: its not only secrets management, the whole stack should go through security hardening and regular security review.
[+] [-] pmontra|5 years ago|reply
[+] [-] lazyant|5 years ago|reply
Hmm no, environments vars are very convenient but leak like crazy easily.
[+] [-] LyndsySimon|5 years ago|reply
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.
[+] [-] aymsic|5 years ago|reply