search

SemkoDev / nelson.cli

WE HAVE MOVED TO A NEW REPOSITORY
https://gitlab.com/semkodev/nelson.cli
ISC License
129 stars 20 forks source link

Why does the docker scripts require network_mode: "host"? This prevents the bound ports from being exposed #23

Open mr-e- opened 6 years ago

mr-e- commented 6 years ago

I have tried using docker-compose and a container link in order to run but it seems like it connects initially but them it starts to error out saying "IRI gone... closing all Nelson connections" even though IRI is running fine and I can query through curl either remotey or on the local box. When I use network_mode: "host" it works but then I am not able to connect to IRI from external to the running box.

I am receiving this error:

Error: Request Error: COMMAND getNeighbors is not available on this node at Object.requestError (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\iota.lib.js\lib\errors\requestErrors.js:11:12) at makeRequest.prepareResult (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\iota.lib.js\lib\utils\makeRequest.js:168:24) at exports.XMLHttpRequest.request.onreadystatechange (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\iota.lib.js\lib\utils\makeRequest.js:62:25) at exports.XMLHttpRequest.dispatchEvent (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\xmlhttprequest\lib\XMLHttpRequest.js:591:25) at setState (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\xmlhttprequest\lib\XMLHttpRequest.js:610:14) at IncomingMessage. (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\xmlhttprequest\lib\XMLHttpRequest.js:447:13) at emitNone (events.js:91:20) at IncomingMessage.emit (events.js:186:7) at endReadableNT (_stream_readable.js:974:12) at _combinedTickCallback (internal/process/next_tick.js:74:11)

docker-compose.yml

version: '2'

services: iota: image: iotaledger/iri:latest ports:

volumes: iota: iota.ini: iota_data: iota_conf:

rosstimson commented 6 years ago

The reason for that is the official IRI image restricts the neighbour API calls: https://github.com/iotaledger/iri/blob/dev/Dockerfile#L16

I definitely don't think it is necessary to use --net host and I'm sure I've seen somewhere in the Docker docs saying you shouldn't do this and it is considered an anti-pattern. The proper Docker networking stuff is the way to go via docker network, or this is of course what Docker Compose does for you by default too. I have a working Docker Compose file that I've been using for early testing if you'd like to try it or compare it with yours: https://gist.github.com/rosstimson/bc0e4bc881e2c333b5bcfdbade720d3d

mr-e- commented 6 years ago

I actually just figured this out and came here to delete this ticket:) I guess the problem with using a docker network will be that I will have to expose those API calls externally as well... but there may have been a good reason IRI put that restriction in? Can you think of any other ways we can restrict those api calls while still allowing access to Nelson?

rosstimson commented 6 years ago

I mainly work with AWS. I figured I'd just not open that port up in the security group (firewall) and use an ssh tunnel if ever I need to connect to it. IRI seems to have a --remote-auth flag where you can secure calls with a token but I'm not sure Nelson supports that yet.

nuriel77 commented 6 years ago

Afaik the --remote-auth is simply user:password (in clear text as opposed to what is suggested in the offical docs). It can be called as authentication basic in the URL: 

http://user:password@mynode.com:14265

However, if not served via SSL termination (reverse proxy) the password will be sent not encrypted, which isn't the best for security.

romansemko commented 6 years ago

Do we want to add auth options to Nelson?

H3npi commented 6 years ago

i'd suggest to add auth options to some api endpoints, like peers.