Sharing publicly an API key for read only access


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.

My question is similar to the one in this topic Sharing ML Dataset via read-only access grant, but I am not sure if I am doing it well.

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.

Thank you very much

There are several ways how you can share an access to your object(s)/bucket(s)/prefix(es):

  1. You can generate an access grant and share it with someone to allow them to configure any supported tool and have an access to what you have shared
  2. You can generate a linkshare URL to publish it somewhere on the site or share it with someone. Such URL will be read-only by default.

Regarding configuration of rclone. You can configure it in three ways:

  1. Using an API Key, satellite address and encryption phrase
  2. Using an access grant generated either in the satellite UI or uplink CLI (it actually contain an API Key, satellite address and encryption key derived from your encryption phrase)
  3. 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.

To generate an access grant with the read-only access you need to use the uplink CLI or satellite UI.

The safest method is to generate either an access grant or URL with read-only access from the uplink CLI, but easiest method (however, less secure) is using the satellite UI and Objects browser.

I hope that I answered on your question.

Thanks for the reply.

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
    • using web ui: it’s in the browser’s javascript code (your machine, but hosted js code is executed)
    • 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…

Hi, thanks

  1. Am I wrong if I understand that the encryption secret = passphrase?
  2. 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<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:

uplink share --url --not-after=none --access <access grant|access name> sj://test

You will get an read-only derived access grant, read-only S3 credentials and linkshare URL.

Thank you, I’m getting really close. I have been re-reading all your answers and the one of the other topic linked above, together with the S3 Compatible Gateway information page (Storj-hosted S3 Compatible Gateway - Storj DCS Docs) and the uplink documentation (Uplink CLI - Storj DCS Docs). I think I understand it now much better.

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?:

uplink share --url --not-after=none --register sj://test

And, once S3 credentials and access grant creation, how can I delete them if I need so? In the UI only?


Yes. And you can revoke it separately.

This will produce the same result - you will get an read-only S3 credentials, URL and limited access grant.

You may revoke it, or you may delete the root access grant (or API Key) from the satellite UI, it will revoke all derived access grants at once.


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.

Thank you

if these credentials allows upload to your bucket(s)/prefix(es) someone can abuse your account with excess data and egress.

To see configured accesses:

uplink access list

To remove an access with name my-access:

uplink access remove my-access

If this is a last access, then you can remove the file ~/.config/storj/uplink/access.json instead.