amacneil / docker-bitcoin

Bitcoin images for Docker
https://hub.docker.com/r/amacneil/bitcoin/
MIT License
52 stars 76 forks source link

Enable RPC access by default #25

Closed amacneil closed 7 years ago

amacneil commented 7 years ago

Currently we use the default setting for rpcallowip, which means that you can only interact with bitcoind from 127.0.0.1. This does not make sense when using container networking, because the container is running on a private network and you are unlikely to run commands against it from the same host (except when using host networking). Even if users exposed this port to the host, they would not be able to connect or run bitcoin-cli against it, because bitcoind is running inside a container with a different IP.

This change opens the RPC port up to any host. In reality this means that only containers on the same user defined network will be able to access it, or if users expose port 8332 to the host they will also be able to access it.

I realize that the bitcoin documentation specifically recommends against this setting, however I think the above justification makes more sense in the context of container networking. There is also precedence for opening ports to the world by default in docker images (the default postgres and redis images do the same thing, with similar security implications).

Since this PR only changes our default bitcoin.conf file, it will not affect existing users with a persisted data volume.

The downside to this change is that users are more likely to accidentally expose the RPC interface on a public network (e.g. by mapping port 8332 to the host, or by using host networking). As stated above this is no different than other official docker images. However, for this reason I have not included any examples of mapping ports or host networking in the readme changes, instead suggesting methods which keep the RPC port internal.

Closes https://github.com/amacneil/docker-bitcoin/issues/2 https://github.com/amacneil/docker-bitcoin/pull/22

roshii commented 7 years ago

this all makes sense, I do agree ::/0 is definitely a better option, it covers for any docker's default network changes and doesn't take away any security compare to 172.17.0.0/16 - which I did not realize at first

thanks again