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

21–30 of 77 posts

Re: Supabase Vault

#21

Post by michelpp »

hackandtrip wrote: post #13
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…

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!

Re: Supabase Vault

#22

Post by aidos »

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…

It’s funny reading that comment from the other side of the fence. I’ve not looked closely at Supabase so I have no real opinion on it, but hearing someone say that you need to know Postgres to work with it is reassuring to me.

Edit: don’t take that as a criticism, just more of an observation that there’s a target audience for which is probably hits a sweet spot.

Re: Supabase Vault

#23

Post by michelpp »

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?

If you give a database client access to the decrypted secrets, then they have them. What the client will not have access to is the hidden root key that is not accessible to SQL that pgsodium uses to encrypt and decrypt data.

Re: Supabase Vault

#24

Post by michelpp »

vbezhenar wrote: post #10

Is there any solutions for postgres database encryption at rest (other than using OS-level encryption)?

The Supabase Vault is encryption at rest, the column is stored encrypted in the database, WAL streams and backup dumps. This is usually more efficient than dealing with full disk encryption, and it allows you to control who sees decrypted data on a role-by-role basis using normal Postgres security GRANTs.

With Full Disk Encryption you also only get encryption to that one disk, if you are doing WAL shipping, the disk you are storing the db on may be encrypted, but the WAL files you ship will not be, so you have to make sure those files are encrypted through a full chain-of-custody. With the Vault the data starts off encrypted before going into the WAL stream. Downstream consumers would need to also acquire the hidden root key to decrypt it. We're working on making that process seamless but also secure.

Re: Supabase Vault

#25

Post by [deleted] »

aidos wrote: post #22
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…

It’s funny reading that comment from the other side of the fence. I’ve not looked closely at Supabase so I have no real opinion on it, but hearing someone say that you need to know Postgres to work with it is reassuring to me. Edit: don’t take that as a criticism, just more of an observation that there’s a target audience for which is probably hits a sweet spot.

[deleted]

Re: Supabase Vault

#26

Post by zaroth »

michelpp wrote: post #18
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 yo…

Thank you for the quick reply! I’m not a Supabase customer so apologies if the questions don’t make sense in your context.

But I think it would help to understand if Supabase is fully managing key backup and recovery internally, how exactly is that working?

Ultimately the whole value of TDE at the database layer comes down to two things IMO which are flip sides of the same coin;

1) Being able to store your database backups in less trusted locations,

2) actually keeping the secret data secret, which amounts to keeping that encryption key secured at a much higher level than the database backup itself.

In the end it’s just key vaults all the way down, isn’t it!

Re: Supabase Vault

#27

Post by cpursley »

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…

You just learn Postgres/SQL as you go. And I've gotten much better at it (schema design, functions, querying) after adopting Hasura (similar idea as Supabase). It's an investment that will pay off for any developer and will outlast whatever cool framework of the month.

But yeah, there's room for more higher level abstractions on top SQL databases. Metabase actually has a nice UI for building queries. Maybe something like this would be useful in Supabase: https://www.metabase.com/docs/latest/questions/query-builder...

Re: Supabase Vault

#28

Post by michelpp »

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

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

Re: Supabase Vault

#29

Post by jononomo »

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…

In my humble opinion, if you're a software engineer in the modern world, then learning Postgres is about as fundamental to your job as learning to dribble would be to a job as an NBA basketball player. It is the just the foundation of almost everything else.

Re: Supabase Vault

#30

Post by bastawhiz »

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…

My experience is that Firebase requires you to understand the ins and outs of Firebase, which has no real equivalent. Firebase is notorious for pathological cases and performance cliffs and other "gotcha"s; it isn't magic. Knowing what's going to perform poorly or become unmaintainable or otherwise cause problem requires you to have either prior knowledge or done something wrong and learned the hard way. At least with Supabase, if you know about Postgres, you can bring that knowledge with you.
Post reply on HN