Ability to toggle access to API endpoints grouped together for functionality based control

[Brindrajsinh-Chauhan]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

While searching for ways to limit access to the API endpoints the current option I came across was to provide route based access through Authorizations in the API config. This allows users to set authorizations credentials for specific routes. I think the ability to expose or disallow a group of endpoints can also be valuable.

Just as for many ethereum based chains have the ability to allow access to a set of API's by setting the following config

--http.api=admin,eth,txpool...

Grouping together IPFS API's based on their function/use case and enabling/disabling them through config can allow users to control the endpoints based on their needs and application and allow them to just expose only those.

An Example could be

"API": {
    "AllowGroups": ["p2p", "file", "stats"],

which would only allow apis related to

• peering: Which might include swarm apis to add, remove, list peers
• file: Which might include api to add, cat, cp etc files
• stats: Could allow apis to fetch different stats.

This would let the user access only these apis and prevent config or other such groups of api from being used.

This could also be extended to the Authorizations config by allowing access authorized access to a group of API endpoints instead of having to list out all the needed API's every time.

Happy to work on this.

Thank you

[Brindrajsinh-Chauhan]

@Jorropo Would be grateful to get your thoughts on this or guidance.

[lidel]

Thank you for filling this, some thoughts:

I think the ability to expose or disallow a group of endpoints can also be valuable.
[..]
Grouping together IPFS API's based on their function/use case and enabling/disabling them through config can allow users to control the endpoints based on their needs and application and allow them to just expose only those.

This very thing is already implemented in form of API.Authorizations: AllowedPaths
where you can grant access to specific command, or group of commands under specific path prefix.

Things you requested:

peering: Which might include swarm apis to add, remove, list peers
file: Which might include api to add, cat, cp etc files
stats: Could allow apis to fetch different stats.

Are already possible with existing config:

AllowedPaths: [ "/api/v0/swarm", "/api/v0/add", "/api/v0/cat", "/api/v0/files", "/api/v0/stats"]

---

We've discussed this during triage today:

• Our design decision for API.Authorizations is that it is better for security-sensitive things to be explicit rather than explicit. That is why we have explicit AllowedPaths rather than made-up categories/taxonomy..
• Creating new taxonomy for RPC commands adds another level of abstraction/indirection to Kubo RPC.
  • 👉 New RPC taxonomy would require maintenance time (add additional attribute to every existing RPC command, make sure the attributes are documented) which would be better spent elsewhere

Due to this, we are not planning adding anything beyond already existing AllowedPaths.

If you need different Authorization model, you can implement it as middleware in front of Kubo.