Hi @zesantos!
We have a couple of layers of things -
- An API Key is the credential the Satellite needs to authorize a request. This can be restricted in a variety of ways.
- An Access Grant is a client-side only serialized envelope that contains an API Key and encryption keys for what the API Key allows for. The access grant actually keeps what’s called an “encryption store” which is a serialized database of mappings of path prefixes to derived encryption key roots. This allows you to restrict an access grant to a specific bucket or path without leaking encryption details to other buckets or paths.
- An Access Key is used specifically for our edge services. It is the encryption key for an encrypted Access Grant that our edge services store.
Bummer that Storj has all three, cause that’s a bit confusing. But anyway.
Since you’re building an end to end encrypted app, you’ll mostly want to concern yourself with Access Grants. Access Grants can be created by combining an API Key with a root Encryption Passphrase and a project salt (see RequestAccessWithPassphrase), or just in the web interface, which uses a web assembly Javascript client for calling that method I linked.
Once you have an Access Grant, you can restrict it to just a specific bucket or even to a specific object path prefix. In your case, it sounds like you may want to have a server-side application generate a per-customer AccessGrant that is restricted to a portion of a bucket with a customer specific prefix. Specifically, maybe for customer 1234 you restrict an access grant to customer-data/customer/1234/.
Once you have this restricted Access Grant, of course you want the user to choose their own key - this is where you would have them use OverrideEncryptionKey on the client side, which allows you to specify the encryption information for just a subtree of your project. This allows them to interact with their portion of your bucket in a way that allows for them to keep their keys.
This will allow for each customer to have their own keys and not be able to see someone else’s data, even if they use the same passphrase, since the real encryption keys are derived based not just on the passphrase, but on the salt and path derivation.
From a logistics perspective, you’ll probably want to keep in mind that the uplink cli has some utilities for helping manage encrypted data, such as uplink ls --recursive --encrypted and uplink rm --encrypted --recursive
Does this help?