# Sharing publicly an API key for read only access

**URL:** <https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612>\
**Category:** DCS\
**Created:** [December 6, 2022, 10:52pm UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612 "2022-12-06T22:52:34Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yukon](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/yukon/32/1139_2.png) [@Yukon](https://forum.storj.io/u/Yukon)\
**Post date:** [December 6, 2022, 10:52pm UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/1 "2022-12-06T22:52:34Z")

</div>

Hi

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](https://forum.storj.io/t/sharing-ml-dataset-via-read-only-access-grant/14833), 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

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [December 7, 2022, 5:34am UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/2 "2022-12-07T05:34:10Z")

</div>

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](https://docs.storj.io/dcs/getting-started/satellite-developer-account/access-grants) 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](https://docs.storj.io/dcs/api-reference/linksharing-service) 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](https://docs.storj.io/dcs/how-tos/sync-files-with-rclone) in three ways:

1. Using an [API Key, satellite address](https://docs.storj.io/dcs/getting-started/satellite-developer-account/access-grants#Dq__0) and encryption phrase
2. Using an access grant [generated](https://docs.storj.io/dcs/getting-started/satellite-developer-account/access-grants) either [in the satellite UI](https://docs.storj.io/dcs/getting-started/satellite-developer-account/access-grants#Csdi2) or [uplink CLI](https://docs.storj.io/dcs/getting-started/quickstart-uplink-cli/generate-access-grants-and-tokens/generate-a-token) (it actually contain an API Key, satellite address and encryption key derived from your encryption phrase)
3. Using an [S3 credentials](https://docs.storj.io/dcs/how-tos/sync-files-with-rclone/rclone-with-hosted-gateway) (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](https://docs.storj.io/dcs/getting-started/quickstart-uplink-cli/prerequisites) for the same.  
To share a single object/bucket as an URL you usually uses either [uplink CLI](https://docs.storj.io/dcs/api-reference/uplink-cli/share-command#f-jKX) or [Objects browser](https://docs.storj.io/dcs/getting-started/quickstart-objectbrowser#81Wlr) 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](https://docs.storj.io/dcs/getting-started/quickstart-uplink-cli/sharing-your-first-object) or [satellite UI](https://docs.storj.io/dcs/getting-started/satellite-developer-account/access-grants#Csdi2).

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.

---

<div class="post-metadata">

**Author:** ![Yukon](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/yukon/32/1139_2.png) [@Yukon](https://forum.storj.io/u/Yukon)\
**Post date:** [December 7, 2022, 5:56am UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/3 "2022-12-07T05:56:30Z")

</div>

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.

Tx

---

<div class="post-metadata">

**Author:** ![elek](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/elek/32/9189_2.png) [@elek](https://forum.storj.io/u/elek)\
**Post date:** [December 7, 2022, 7:55am UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/4 "2022-12-07T07:55:52Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Yukon](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/yukon/32/1139_2.png) [@Yukon](https://forum.storj.io/u/Yukon)\
**Post date:** [December 7, 2022, 10:05pm UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/5 "2022-12-07T22:05:16Z")

</div>

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](https://forum.storj.io/t/sharing-ml-dataset-via-read-only-access-grant/14833/3)  
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)

Thanks

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [December 8, 2022, 4:31am UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/6 "2022-12-08T04:31:17Z")

</div>

> [@Yukon](#):
>
> Am I wrong if I understand that the encryption secret = passphrase?

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.

> [@Yukon](#):
>
> do you think his advice is still valid?

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:

```auto
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.

---

<div class="post-metadata">

**Author:** ![Yukon](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/yukon/32/1139_2.png) [@Yukon](https://forum.storj.io/u/Yukon)\
**Post date:** [December 10, 2022, 12:57pm UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/7 "2022-12-10T12:57:32Z")

</div>

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 ([S3 Compatible Gateway Hosted by Storj - Storj Docs](https://docs.storj.io/dcs/api-reference/s3-compatible-gateway)) and the uplink documentation ([Using the Uplink CLI - Storj Docs](https://docs.storj.io/dcs/api-reference/uplink-cli)). I think I understand it now much better.

> [@Alexey](#):
>
> > [@Yukon](#):
> >
> > do you think his advice is still valid?
> 
> 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,

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)

> [@Alexey](#):
>
> 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.

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?

> [@Alexey](#):
>
> The shortest way is:
> 
> ```auto
> 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.

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

```auto
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?

Thanks!

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [December 10, 2022, 3:08pm UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/8 "2022-12-10T15:08:19Z")

</div>

> [@Yukon](#):
>
> 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?

Yes. And you can [revoke](https://docs.storj.io/dcs/getting-started/quickstart-uplink-cli/sharing-your-first-object/revoke-an-access-to-an-object) it separately.

> [@Yukon](#):
>
> But how is that different from the following? Which one is safer?:
> 
> ```auto
> uplink share --url --not-after=none --register sj://test
> 
> ```

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

> [@Yukon](#):
>
> And, once S3 credentials and access grant creation, how can I delete them if I need so? In the UI only?

You may [revoke](https://docs.storj.io/dcs/getting-started/quickstart-uplink-cli/sharing-your-first-object/revoke-an-access-to-an-object) 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.

---

<div class="post-metadata">

**Author:** ![Yukon](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/yukon/32/1139_2.png) [@Yukon](https://forum.storj.io/u/Yukon)\
**Post date:** [December 11, 2022, 5:38pm UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/9 "2022-12-11T17:38:24Z")

</div>

Thanks.

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

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [December 12, 2022, 3:58am UTC](https://forum.storj.io/t/sharing-publicly-an-api-key-for-read-only-access/20612/10 "2022-12-12T03:58:55Z")

</div>

> [@Yukon](#):
>
> 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.

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

> [@Yukon](#):
>
> 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?

To see configured accesses:

```auto
uplink access list

```

To remove an access with name `my-access`:

```auto
uplink access remove my-access

```

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