Hacker News Reader

Comment by nicoburns | Hacker News Reader

Hmm... I feel like secrets are the one thing I don't want to be in Postgres... because I want to store my Postgres credentials in the secrets vault! And I certainly don't want to have to update the configuration for every service which accesses my secrets vault every time I upgrade my Postgres database (and the access URL changes).

IMO nobody's doing secret management for small companies / products particularly well, so there's definitely a niche to be filled here. But I'm not quite convinced this is it...

View on HN

There are a ton of companies that do this as a service:

- https://www.doppler.com/ (my favorite)

- AWS Secrets Manager

- Google Cloud Secret Manager

- Azure Key Vault

- https://AKeyless.io

- https://EnvKey.com

Then, there's a few companies that do OSS solutions:

- Hashicorp Vault (https://vaultproject.io)

- CyberArk Conjur / Secretless (https://github.com/cyberark)

I'm sure there are lots that I've missed.

What makes Doppler your favorite out of this list?

As a security guy, I'm always worried about secrets living in Env variables because it's an easy place for them to leak. (Many loggers will automatically log env vars, for example.)

That's why many services, like Kubernetes, have moved away from this model by either serving the secrets up in a runtime-mounted file (like /var/secrets.yaml) or by requiring you to make an explicit API call (SecretsManager.readSecret("foo")).

From a security perspective, those paths require a much more difficult exploit like full Remote Code Execution (RCE) in order to leak values.

The downside is that it requires modifying application logic to migrate away from Env vars though. Usually it's pretty easy, but if you have tons of legacy code I'm sure that often presents a challenge.

Vault supports reading secrets from a file when using Nomad.

> Hmm... I feel like secrets are the one thing I don't want to be in Postgres... because I want to store my Postgres credentials in the secrets vault! And I certainly don't want to have to update the configuration for every service which accesses my secrets vault every time I upgrade my Postgres database (and the access URL changes).

Password storage is a somewhat different problem, if you're checking passwords, you just need to know it's authentic, not the actual password itself, so it's common to use hashing and salting techniques for this (pgsodium exposes all of the libsodium password and short hashing functions if you want to dig further) your best bet here is to use SASL with SCRAM auth for postgres

https://www.postgresql.org/docs/current/sasl-authentication....

Secret storage is more about encrypting and authenticating data that is useful for you to know the value of. For example you need the actual credit card number to process a payment (waves hand, this is a broad subject, and some payment flows do not require the knowledge of CCN) but you want to make sure that number is stored encrypted on disk and in database dumps. That's the use case the vault is hitting.

We also have some upcoming support for external keys that are stored encrypted, so for example you can store your Stripe webhook signing key encrypted in pgsodium and reference it by key id that can be passed to `pgsodium.crypto_auth_hmacsha256_verify()` to validate a webhook callback instead of the raw key itself.

Ideally, you could have a Postgres instance specifically dedicated for secrets - I don't see why you should couple sensitive and non-sensitive data. Many OSS services like HashiCorp Vault just do that: you give Vault a backend (which can be a Postgre DB, just like the one Supabase is offering) and it's gonna use that to save the secrets.

You could then use (e.g.) OpenID to connect to the specific instance of Supabase with those secrets from your application

We are considering running the Vault in Trusted Execution Environments (TEE) that are similar to encrypted VMs, where the memory traffic to the cpu is encrypted until it hits the processor. We're still investigating this possibility but it would make for a more secure cloud environment for sure. Of course AWS charges quite a premium for them!

Hashicorp Vault is always my goto even for small companies. It seems too much but it’s really not. A single instance is scalable enough to handle quite a bit of traffic.

Another good alternative if you need something more SAASy is the 1pass API product

There's also https://www.doppler.com/!

I felt the same but it was too hard to find people that knew how to operate Vault and so we abandoned it since it was too risky to have such a critical part of our infra without an abundance of talent out there.

https://learn.hashicorp.com/vault ok then hire some random joe shmoe sysadmin and teach them.

+1 for Hashicorp Vault, it's amazing and easily extendable. My plugins which I developed years ago still work with the latest version.

I’m confused on why secret management considered secure. Maybe I’m missing something.

Why is letting a third party managed your secrets is secure? So if that third party gets compromised, they now have access to all your secrets. Amazon or other company employees can also view your secrets.

If your server gets compromised, the secrets that are accessible via that server are also compromised. Isn’t that the same impact as just keeping the secrets on your server? Maybe worse if your permissions are broad. You’re merely adding an extra step to get the secret from your secret management.

Speaking for EnvKey (mentioned above—I’m the founder), we use client-side end-to-end encryption to address this concern. Secrets cannot be accessed on an EnvKey server.

I’m biased, but I share your skepticism of secrets management services that don’t use end-to-end encryption. It’s not a wise choice for either the service provider or its users.

Can you shed some light here

If I need access to a decryption key to read my secrets or to provide my secret to a process I still have to manage my decryption key which means I might as well use that process to manage my secret

A short list of additional benefits:

- Secrets are automatically kept in sync across multiple processes and servers.

- Easily and securely give other developers access (to what they need, and no more).

- You can automatically reload a process when secrets update.

- All updates and accesses are logged.

- End-to-end encrypted version control.

- You can limit access to specific IPs or IP ranges.

- You can edit multiple environments side by side (development, staging, production, etc.)

- You can use de-duplicate across environments and apps using inheritance or stackable ‘blocks’ of config.

...and you managing your own secrets is way better than a third party?

wake up people, its all the same types of servers managing the same type of passwords with the same types of security layers, not one is better than the other! nobody has a 'secret sauce' to storing your passwords.

exactly, we would stick to AWS Secrets

Reply on news.ycombinator.com