[chasd00]

forgive my ignorance first of all.

One of the things i was going to work on this weekend was an enhancement to a side project and it involves storing some sensitive information in a database. My usual way of doing this is strong encryption in the application code with a key from an environment variable then base64 encode the result and put it in a text column.

Is Vault something that can handle this without getting into my app code? Basically, if i gave a someone root access to my supabase instance is that encrypted data safe?

PS the more i read about supabase the more magical it becomes. It's incredible work so congratulations, i love it.

[michelpp]

> Is Vault something that can handle this without getting into my app code? Basically, if i gave a someone root access to my supabase instance is that encrypted data safe?

The answer is slightly offset from your question, so let me start by pointing out that the Vault is about Encrypted Data At Rest. This is mentioned in the docs and in the blog and video, but it's something that I like to always mention first in discussions. The main purpose of the Vault is to store your data encrypted, so that it's encrypted on disk, and in backups. In SQL the decrypted secrets are available to you, because that's where you are using them and encrypted data must be decrypted to be useful.

If someone roots access to your database, then yes they can access the decrypted secrets through the view. This is by design, the secrets must be decrypted to be useful in query code. This risk is similar to someone rooting your application code, they will see decrypted secrets via your environment key, so no it won't protect you against anyone rooting processes in your stack that need useful access to secrets and it's not meant to. Like all security you must take a layered approach, the Vault is just one storage level layer strategy.

One big difference from the env var approach though is that the key Supabase uses to encrypt your secrets with the Vault is stored outside the database, it is inaccessible to SQL, which is an enhancement over sticking the raw key into an environment variable or a table that is accessible to your application. Instead of revealing the raw key, pgsodium has a feature called [Server Key Management](https://github.com/michelp/pgsodium#server-key-management) where you do not have access to the raw key, but instead reference keys by an key identifier. It is safe to store this identifier alongside the data it encrypts. The raw key itself is never stored. I'm very intentionally overusing the word "store" here, because that's specifically the layer of security that the Vault provides.

[robszumski]

I'm building the "in-use" part of this right now...what if you could encrypt your data with an encryption key (at-rest), but also to a set of code that is allowed to decrypt it (in-use). If that code is identified cryptographically, its identity can't be spoofed or stolen.

We're exploring secure enclaves as the protected runtime env and the code attestation generation: https://github.com/edgebitio/enclaver

This post has made me add pgsodium to my reading list :)

[michelpp]

One benefit of the approach we are taking is that you can use regular Postgres security rules and policies (GRANTs, RLS, etc) to constrain access to decrypted secrets. It's not quite going all the way to encrypted VMs, but it's better than all or nothing.

Secure enclaves is something that is on our list, one issue we have is that so many of our components we ship are extensions and open source projects, attestation becomes very hard. We've considered a very, very minimal postgres build with almost no extensions enabled except pgsodium, which would run on an encrypted VM purely for the purposes of secret storage, but then "in-use" becomes rather restricted. Definitely open to hearing any ideas you may have on the subject!