Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase Vault

supabase.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Supabase Vault

#61

Post by freeqaz »

brainbag wrote: post #14
mahmoudimus wrote: post #11

Earlier quoted context omitted.

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.

Re: Supabase Vault

#62

Post by freeqaz »

tmd83 wrote: post #15

What I don't understand (perhaps I haven't found the right docs to read) is how to safeguard the secret if a client machine of the secret is compromised. Say I have a web server that's connecting to the database and the database credential are stored in some separate value. If someone get's access to the web server machine can they not access the value from there?

So I've actually spent about a year of my life working to solve this exact problem. Specifically: How do you prevent a single point of failure from leaking everything sensitive in a database.

It turns out that it's a pain in the rear, but it's possible. You can read through the docs about the design on the site[0].

The parts that I haven't implemented yet, and that limit it's utility in production, are around searching the encrypted data (requires a second vault using asymmetric encryption) and some more in-depth disaster recovery (secure token recovery).

Here is a link to the GitHub[1] for it all.

0: https://www.lunasec.io/docs/pages/lunadefend/overview/introd...

1: https://github.com/lunasec-io/lunasec/tree/master/lunadefend

Re: Supabase Vault

#63

Post by [deleted] »

justsomeuser wrote: post #33
brap wrote: post #17

I’m really impressed with everything Supabase does, but… They market themselves as the “open source alternative to Firebase”. Which is great, mainly because you don’t have to worry about vendor lock-in (to an extent). Yet one of the main selling points of Firebase (at least in my humble opinion) is that you don’t have to concern yourself at all with implementation details and stuff like that. The learning curve is sm…

With Firebase you have a team managing the service uptime. When I last checked, Supabase is a group of processes that you manage yourself. This means that: - A. If something goes wrong or you need to customise something, it would be quite complex to fix as you have all these different processes and code bases to understand. The sum of depended-on lines of code for all the open source code bases in Supabase would be m…

[deleted]

Re: Supabase Vault

#64

Post by zaphirplane »

danenania wrote: post #41
byteshock wrote: post #32

Earlier quoted context omitted.

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

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

Re: Supabase Vault

#65

Post by atonse »

chucky_z wrote: post #6
nicoburns wrote: post #4

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

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

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.

Re: Supabase Vault

#66

Post by atonse »

kiwicopple wrote: post #59
eddieroger wrote: post #58

Earlier quoted context omitted.

I figured there would be a comment like the one to which you responded, but didn't expect it to be the bottom one, downvoted to obscurity. Vault is an already heavily used word, with Hashicorp being the big player with it, and Ansible a second. There are a lot of words that could be used, and it is kind of a shame that one already associated to a big player in the secrets management game was the one used here.

That’s actually _why_ we used it - the name is well-used enough that people understand what it means and what it does without further description. That said, this is good feedback - we’ll reconsider the name. (If anyone else has an opinion for/against, let us know - the reason for this pre-release is specifically to get feedback)

For what it's worth, I think keeping it named vault helps exactly with your intent, it signals that the product is a secrets management product (or something used to store extremely valuable data)

Re: Supabase Vault

#67

Post by danenania »

zaphirplane wrote: post #64
danenania wrote: post #41

Earlier quoted context omitted.

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.

Re: Supabase Vault

#68

Post by digianarchist »

freeqaz wrote: post #61
brainbag wrote: post #14

Earlier quoted context omitted.

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("fo…

Vault supports reading secrets from a file when using Nomad.

Re: Supabase Vault

#70

Post by kiwicopple »

wizwit999 wrote: post #69

Why put everything in your database?

All data goes in _a_ database, we’re just providing an extension in case you put sensitive data in your own. Developers often store sensitive data, this extension ensures that it’s encrypted at rest so that it doesn’t leak to logs and backups.

Specifically for Supabase customers, we have another extension called pg_net, which can send database changes to external systems asynchronously (called “database webhooks”). One of these systems could be, for example, AWS Lambda, but to do that we will need a Lambda execution key. Vault allows users to safely store this key inside their database, and because it’s co-located with the data the payload can be sent immediately via a trigger (and end-to-end encrypted).

Vault will expose a lot of libsodium functions that are useful to developers - encrypting columns, end-to-end encryption, multi-party encryption for things like chat apps, etc

Post reply on HN