Secure/Authenticated API access

[Stebalien]

Currently,

1. Anyone on a machine running IPFS can access the IPFS API over the HTTP interface. This means any user can, e.g., read any running daemon's private keys.
2. Anyone on a machine can run an IPFS server on the standard IPFS port and the IPFS client will blindly use it. This means that a malicious user could impersonate the IPFS server.

Solutions:

1. Use unix domain sockets. The daemon could expose the API over one or more unix domain sockets. If multiple sockets are used, administrators could control access to various APIs using standard unix permissions (this doesn't require multiple sockets but that might make implementation easier).
2. Use HTTP authentication and store some API key in the IPFS directory. With this method, care must be taken to authenticate both ways.

[ghost]

We, at INFURA, really need to work on some kind of implementation for authentication of the API. This element, indeed, has a priority a little higher than developing ipfs-cluster 😬.

I know @jbenet you told me that IPFS daemon is not meant that way. But the need is there, to provide a daemon to people to upload and pin files. I had a quick conversation at DevCon2 with @whyrusleeping, and was suggested to build a specification, to discuss and implement.

So my question: Where do we move this conversation, so I can start a specification and implement it? In this repository? In ipfs/specs?

Thank you y gracias por la paciencia, los últimos meses han sido una locura!

HJ.-

[Kubuxu]

There is also #1532

[ghost]

@Kubuxu Cool. @jbenet told me there was a more mature issue. So, that was it 😄

Thanks!

[sebs]

I like this a lot.

[NotBad4U]

Any update on this ? For now, we just put the IPFS API behind a wireguard but that can be very profitable to have a way to add auth in the IPFS API for ACL.

[Stebalien]

No. The current way to do this is to stick an NGINX proxy out in front of the API and authenticate with that.

[ghost]

If I understand correctly, the current setup means anyone on localhost is privileged to interact with the API?

[Jorropo]

If I understand correctly, the current setup means anyone on localhost is privileged to interact with the API?

You can use unshare and cgroups to create multiple permissioned loopbacks (docker, lxd, ... make thoses features available conveniently).

[Jorropo]

@OpenOS-Project-Creator-Founder

Maybe this could help?
Making the entire Linux Kernel & Linux Kernel Based-Distros from head to toe & from power on state to power off state an entire IPFS Node + Cluster + Pinning Service + Gateway....?

No, asking peoples to run a custom kernel that ships with a bunch of extra features is a far too big ask and not pratical for this rather simple problem, using custom kernels with many cloud providers is really painfull.

I personally prefer people using reverse proxies, vpns or tunnels. I use ssh tunnels myself.