Exposing part of the kubo RPC API

Help Kubo
1

In the Kubo RPC API doc, it is written that it must not be exposed to the public internet:

NEVER EXPOSE THE RPC API TO THE PUBLIC INTERNET

The RPC API provides admin-level access to your Kubo IPFS node, including /api/v0/config.

It is bound to localhost by default on purpose. You should never expose it to the public internet, just like you would never expose a SQL database or other backend service.

If you are looking for an interface designed for browsers and public internet, consider implementation-agnostic HTTP Gateway instead.

That makes sense, since a lot of operations are admin level. However, this could be interesting to expose a subset of this API behind some restrictions to be able to “lend” an IPFS node to use case where we can not embark one in the app or it does not make sense.

For example, we could expose:

  • /api/v0/dag/put behind a rate limiter, knowing that spam could trigger garbage collection but with a frequency limit
  • /api/v0/pin/add behind a password protection in http header so that trusted users can pin some files

Is there a known project which achieves that? Or is it a terrible idea? That would allow to use a remote IPFS node without system level VPN setup for instance.

2

That’s the goal of kubo/docs/config.md at master · ipfs/kubo · GitHub

API.Authorizations

The API.Authorizations field defines user-based access restrictions for the Kubo RPC API, which is located at Addresses.API under /api/v0 paths.

3

A problem is that we can not separate easily put and pin because pinning is available as an option of put:

/api/v0/block/put

Store input as an IPFS block.

Arguments

  • pin [bool]: Pin added blocks recursively. Default: false. Required: no.

Putting is not a problem because even if garbage is produced, it can be collected, but pinning prevents garbage collection, and I would like to prevent it. Is there a way to disable pinning in node config?

4

Seems that setting max storage to zero could be a workaround:

But then, would the node still accept to store new blocks?

5

I think nodes reporting 0 free space are not allocated any content by ipfs cluster, but Kubo does remain fully operative.

1 Like