Live data from Hacker News

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

blog.gitguardian.com

11–20 of 36 posts

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

#11

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 gen…

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.

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

#12
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.

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

#13

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 gen…

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.

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

#14
> 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.

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

#16

> 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.

I laugh every time I see KMS used as the initialism for that, because in my circles that's short for "Kill MySelf."

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

#17
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.

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

#18
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.

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

#19
For storing secrets as environment variables on your local machine I recommend envchain: https://github.com/sorah/envchain

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)?

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

#20
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).

Feel free to create a free account (no cc required) at https://doppler.com

Post reply on HN