I am building a kind of knowledge database in plain text files that I need to be accesible directly by anyone who is interested on it. So I share to the general public some documents in a read only bucket. But I am wondering which is the safest/correct way to do that. I am using rclone as it fits just fine for the need to mount the bucket in the respective devices.
I have generate an API key with read and list permissions only for a bucket created just for this use. Then I use “rclone config” to build the remote access (.conf file).
What I don’t understand very well is that although I create the access during the configuration of rclone, at the end the .conf file shows not only the satellite_address and the api_key, but also the passphrase and an access_grant, thus I don’t understand the recommendation done in the linked topic, neither if it is safe.
As this is my first time configuring this type of access I would really thank if someone could advice the best (safe) way to do that.
Using an S3 credentials (they uses an access grant under the hood, registered on our auth service).
Usually you configure rclone with access grant (or API Key, satellite address and encryption phrase) with write permissions to be able to upload and download your files. You may also use an uplink CLI for the same.
To share a single object/bucket as an URL you usually uses either uplink CLI or Objects browser and the generated URL will be read-only by default. But if you want to share several objects/buckets/prefixes at once, you will use the uplink CLI only.
Yes, I don’t count to share the bucket by url, so the UI / Objkects browser is not used.
But I understand that either using and API key or Access grant generated in the satellite UI or uplink CLI, is equally safe, it isn’t? I understood in the topic linked that there was some difference regarding safety.
There is no big difference IMHO, only if you use S3 credentials vs access grant.
As a reminder: Access grant = API key + encryption secret
If you use generated S3 compatible credentials: you trust in Storj Labs (grant is stored in an encrypted from in Auth service operated by Storj Labs, you have the key to decrypt it, and you send it with every request.)
If you generated access grant: the question is where do you add encryption secret to the api key
uplink cli: it’s your terminal (which might be safer, assuming it’s easier to audit the source of the terminal binary)
The second two are very close to each other (IMHO), unless you would like to audit the source code…
Am I wrong if I understand that the encryption secret = passphrase?
Then, my safety concern is now more related to the fact that I will be sharing the access grant to everybody. Although the access is list and read only, could it be a security risk? I mean, will it allow someone to make some malicious use of it? I was reading this post by jtolio here Sharing ML Dataset via read-only access grant - #3 by jtolio
do you think his advice is still valid? Has this “flaw” been addressed? He recommends an access key, which I understand is a S3 access which a priori I did not want to use (and access grant seems safer)
Encryption secret (encryption key) is derived from your encryption phrase (passphrase), like in Bitcoin or Ethereum wallets - you may have dozens of encryption keys, derived from your encryption phrase.
Yes, it’s still valid, especially if you shared an access grant generated in the satellite UI - your access grant will have a default key and this fact could be exploited too.
So the better approach is to register your access grant (with uplink access register --public=true <access grant|access name>) and get S3 credentials, they still can be used in rclone and you can use your S3 access key with linkshare service to produce an URL https://link.storjshare.io/<access key>/<bucket>/<prefix/object>
Or at least generate a derived access grant in the uplink CLI using uplink share command if you need to use it in libuplink (native integration).
If you going to share S3 credentials (which is not needed, since you can give just an URL to your bucket(s)/prefix(es)/object(s)), then you can register a derived access grant (to do not trust us your default key even in encrypted form) and generate even more safe S3 credentials.
The shortest way is:
I understand here that you are referring to obtaining an access key (“get S3 credentials”) based on an already existing access grant that I have generated in other place (UI or rclone with API key, for example)
By derived, I understand you mean to generate another access grant based on the existing one (from one generated already in UI, for example), is my understanding correct?
I understand this command will generate a new derived access grant, and give me the S3 credentials (and URL).
But how is that different from the following? Which one is safer?:
I have tested with uplink setup and configured the S3, it works. I have two comments/concerns though:
1- When I configure rclone with the S3 credentials, I’ll share an access_key_id, the secret_access_key and the endpoint. These other data aside of the access key do they present some risk? I understand, no, but I wanted just to have your feedback, if possible.
2- I wanted to delete the uplink access I have just done (done for testing), but as it is the only one I configured with uplink, it becomes the current/default and I can’t revoke neither remove it. I have just deleted all my buckets and access grants through the UI, but the uplink access do still exists (“uplink access list” shows it). How can I delete it if it is still the current/default one? I could of course delete the access.json file, but that seems just to hide it to my eyes, as the access may be active anyway.