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

11–20 of 77 posts

Re: Supabase Vault

#11

Post by mahmoudimus »

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

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.

Re: Supabase Vault

#12

Post by dinkledunk »

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

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

Re: Supabase Vault

#13

Post by hackandtrip »

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

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

Re: Supabase Vault

#14

Post by brainbag »

mahmoudimus wrote: post #11
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,…

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?

Re: Supabase Vault

#15

Post by tmd83 »

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?

Re: Supabase Vault

#16

Post by jjnoakes »

zaroth wrote: post #2

One thing I think missing from this write-up is to walk through how the Restore process will work with encrypted data under pgsodium. Namely what will happen when you first restore some data into a new Postgres instance which booted with its own randomly generated root key (the wrong key) and then how you are supposed to patch in the correct key and be able to start reading secrets again? Also, how does the decrypted…

The article links directly to here, which may answer your question:

https://github.com/michelp/pgsodium#server-key-management

Re: Supabase Vault

#17

Post by brap »

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 small, you get a database without having to think about databases.

Yet everything I read about Supabase is heavily centered around Postgres, it seems like you really need to know the ins and outs of the database. I wouldn’t really feel comfortable adopting Supabase without taking a class in Postgres first.

I’m wondering if Supabase plans to stay “low level” or give a higher level of abstraction to those who want it.

Edit: just want to clarify, I’m not saying “sql bad”, I’m saying there’s a not-so-small market (mostly beginners) who would see this as a big adoption barrier, which I think is understandable. I don’t know if Supabase wants to (or even should) cater to both markets.

Re: Supabase Vault

#18

Post by michelpp »

zaroth wrote: post #2

One thing I think missing from this write-up is to walk through how the Restore process will work with encrypted data under pgsodium. Namely what will happen when you first restore some data into a new Postgres instance which booted with its own randomly generated root key (the wrong key) and then how you are supposed to patch in the correct key and be able to start reading secrets again? Also, how does the decrypted…

> Namely what will happen when you first restore some data into a new Postgres instance which booted with its own randomly generated root key (the wrong key) and then how you are supposed to patch in the correct key and be able to start reading secrets again?

We restore you're original key into new projects. There is also WIP on accessing the key through the API and CLI.

> Also, how does the decrypted view look if you try to read it with the wrong key loaded?

The decryption will fail (pgsodium will thrown an error).

> Do you have to worry about a race condition where you boot an instance with some encrypted data but forget to put the key file in place, and then end up with a new random key, saving some new data, and now you have a mix of rows encrypted with two different keys? Or will the whole subsystem block if there’s data stored that can’t be decrypted with the resident key?

There's no race in the system, your key is put in place by us before the server boots.

Thanks for the feedback! I'll put some more thought into your question about authenticating a key is the original before you use it.

Re: Supabase Vault

#19

Post by zaroth »

jjnoakes wrote: post #16
zaroth wrote: post #2

One thing I think missing from this write-up is to walk through how the Restore process will work with encrypted data under pgsodium. Namely what will happen when you first restore some data into a new Postgres instance which booted with its own randomly generated root key (the wrong key) and then how you are supposed to patch in the correct key and be able to start reading secrets again? Also, how does the decrypted…

The article links directly to here, which may answer your question: https://github.com/michelp/pgsodium#server-key-management

It doesn’t seem to address the negative test cases either!

Re: Supabase Vault

#20

Post by kabirgoel »

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…

Agreed. I used Supabase for a fairly simple project and felt like I had to know a lot about Postgres to implement anything. If you’re building something yourself, I feel like Firebase is still the safer bet. I’m guessing Supabase really shines when you’re building a startup or have a team.
Post reply on HN