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

31–40 of 77 posts

Re: Supabase Vault

#31

Post by byteshock »

michelpp wrote: post #23
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.

But if they have the decrypted secrets, do they really need the key?

Re: Supabase Vault

#32

Post by byteshock »

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

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.

Re: Supabase Vault

#33

Post by justsomeuser »

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

- B. You are tightly locked in. Once you code against the Supabase API's you will not be able to move your app off of it. Other API's lock you in too, but because Supabase does so many things you would need to replace a lot of functionality all at once to move away.

Re: Supabase Vault

#34

Post by solarkraft »

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…

You do lock yourself into the software, but at least not a vendor.

Re: Supabase Vault

#35

Post by michelpp »

byteshock wrote: post #31
michelpp wrote: post #23

Earlier quoted context omitted.

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.

But if they have the decrypted secrets, do they really need the key?

The Vault will not prevent someone who has login access to your database and the right grants (or superuser) from decrypting the data. If someone is in this position they are fully compromised and the Vault is not protection against that (nor is anything else really).

In particular if an attacker has a postgres superuser login they can essentially asct as the OS process owner, and could possibly get around the process hardening we already employ to reduce that risk, but again Vault is not designed to protect against a full superuser exploit. You must carefully guard database login access.

However, the secret data that is stored on disk, in WAL logs, and in database dumps is encrypted. This way you are ensured that your secrets are encrypted at rest. The Vault also provides using standard Postgres privilege access control (via GRANT/REVOKE) to control access to the decrypted data.

Re: Supabase Vault

#36

Post by lghh »

jononomo wrote: post #29
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.

You can go your entire career and never use Postgres. It’s pretty easy to, actually.

Re: Supabase Vault

#37

Post by mavelikara »

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…

What are good resources to learn the "ins and outs" of Postgres?

Re: Supabase Vault

#38

Post by burggraf »

solarkraft wrote: post #34
justsomeuser wrote: post #33

Earlier quoted context omitted.

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…

You do lock yourself into the software, but at least not a vendor.

Supabase developer here. True to an extent, but at least with the data, it's PostgreSQL, which you could take somewhere else. Or you could easily port it to another brand of SQL and do something else with it.

And as far as being "locked into the software", isn't that pretty much true of your entire stack? Once I choose to develop in React, I'm locked into that, right?

Re: Supabase Vault

#39

Post by burggraf »

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…

Supabase developer here. Firebase has a team managing service uptime. Supabase has a team managing service uptime. If you self-host Supabase, you have to manage uptime yourself. You can't self-host Firebase.

Regarding lock-in, you're pretty much right here, but this is going to be true of your entire stack. If you choose to develop your frontend in React, or Angular, or Vue, you're going to be locked into that framework.

"...because Supabase does so many things..." is a good thing, IMHO. You can choose to use any or all of our product, and each piece you choose is open-source. If, say, you choose to use Supabase Storage, and you have an issue with it, you can switch to something else but still use Database, Auth, and Functions without bringing down your entire project.

Re: Supabase Vault

#40

Post by jackconsidine »

I'm so excited for Supabase. As soon as they move Realtime Subscriptions out of alpha / beta, I will replace Firebase on all new projects. The Firebase / Firestore analog - Snapshot Listeners - give your application a real-time backend for free and simplifies state management drastically since your subscriptions are your store.

Supabase being built on SQL is interesting to me- I love PSQL and the row-level security rules are incredible. But the historical SQL v NoSQL debate involves the trade-offs of Consistency, Availability, and Partition Tolerance [0]. With Firebase (and typically NoSQL) you lose Consistency and you get a bit of redundance by virtue of using onWrite listeners as opposed to Joins. That model scales really well since it's amenable to sharding seamlessly. What will scaling a Supabase backend look like?

[0] https://www.bmc.com/blogs/cap-theorem/

Post reply on HN