10 ms·
Supabase Vault
- throwgawag1 4y ago> Vault is a thin usability-layer on top of pgsodium. Cloudflare and Duck Duck Go also add a bunch of names to routine things that already exist. It's better to just not name it.
- mahmoudimus 4y agoSorry, can you help clarify your comment? Do you mean that it's better to not call this "Supabase Vault" and just say "Secrets Management available in Supabase" ?
- eddieroger 4y agoI 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.
- kiwicopple 4y agoThat’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)
- atonse 4y agoFor 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)
- zaroth 4y agoOne 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 view look if you try to read it with the wrong key loaded? 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?
- jjnoakes 4y agoThe article links directly to here, which may answer your question: https://github.com/michelp/pgsodium#server-key-management https://github.com/michelp/pgsodium#server-key-management
- zaroth 4y agoIt doesn’t seem to address the negative test cases either!
- michelpp 4y ago> 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.
- nicoburns 4y agoHmm... 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...
- chucky_z 4y agoHashicorp 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
- gtmtg 4y agoThere's also https://www.doppler.com/ https://www.doppler.com/!
- dinkledunk 4y ago+1 for Hashicorp Vault, it's amazing and easily extendable. My plugins which I developed years ago still work with the latest version.
- atonse 4y agoI 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.
- chucky_z 4y agohttps://learn.hashicorp.com/vault https://learn.hashicorp.com/vault ok then hire some random joe shmoe sysadmin and teach them.
- 4y ago
- vbezhenar 4y agoIs there any solutions for postgres database encryption at rest (other than using OS-level encryption)?
- michelpp 4y agoThe 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.
- tmd83 4y agoWhat 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?
- michelpp 4y agoIf 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.
- byteshock 4y agoBut if they have the decrypted secrets, do they really need the key?
- michelpp 4y agoThe 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.
- tmd83 4y agoI wasn't talking just about pgsodium or the vault product but similar products in general. I understand the point of the database client having access to to the database key and not the key to the secret vault. So in this case other secrets at the vault are essentially protected. But let's say I really have this one secret to protect in which case is the vault fairly pointless? Is it essentially that if a client using KeyX for some purpose than a compromise of said client will essentially lead to KeyX and there's really no way to protect it?
- brap 4y agoI’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.
- kabirgoel 4y agoAgreed. 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.
- aidos 4y agoIt’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 4y ago[deleted]
- zinclozenge 4y agoHonestly, only to the extent that you need to set up your schema. But if your queries aren't too complicated, you can just use the client which is fairly straightforward.
- jackconsidine 4y agoI'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/ https://www.bmc.com/blogs/cap-theorem/
- deleted 4y ago[deleted]
- wizwit999 4y agoWhy put everything in your database?
- kiwicopple 4y agoAll 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