-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to use API port with docker due to 127.0.0.1 binding #229
Comments
that would be really bad as a default for non docker users and a great way to get hotspot signing apis exposed to the internet. I'm not sure how to solve this yet since we're really trying to avoid having people inadvertently or maliciously get convinced to basically expose their key material to the internet. You can't run docker commands to access that api within the docker context using docker scripts? |
One option for us not to build the hole into the core service is for the person building the container to explicitly decide they want this and use socat (or nginx for a larger option) to forward requests. That way you are deciding to expose your keys to the internet |
Hmph.. we'll get it fixed up. I have the same issue talking from gateway-config |
Actually @joecryptotoo. This can be solved by enabling host networking in this docker file which would then have it listen in the host environment. Besides being better than docker based networking this would make it very clear who's exposing the port. Does that work for you? |
@madninja if we make this container to use host networking. All users of this service will also have to use host networking. I think allowing listen ip configuration in settings file will be better. |
I'm not sure I agree.. While it's certainly easier, it also makes it extremely easy for users to expose the local api to the internet which would be a massive security hole. Given that the vast majority of makers are not very security aware we decided to force the docker users to declare that they're doing this in the docker environment. If you have an alternate way to avoid people to yolo expose their signing keys to the internet I'm open to suggestions. |
@madninja this isn't really a viable option. I agree with having the service bind on However, as @joecryptotoo correctly points out, this isn't workable in Docker. We need the be able to talk to Introducing something like a reverse proxy is bad as it adds a lot more complexity. Moreover, this goes against Docker best practice, where you're only supposed to run one 'main' process per container. |
Docker supports better options for this type of operation without compromising the security of the application running directly within the host's network namespace. Running the So for instance running gateway-config within a container on docker's default network Aside from avoiding exposing a security vulnerability, by docker's own admission (https://docs.docker.com/network/host/) there are optimizations to be had by running in host network mode, particularly when you're targeting low latency and high throughput by eliminating the additional hops the bridge network creates between your service and the outside world:
Docker's improved the performance of their bridge network over the years but they still consistently underperform in bandwidth and latency benchmarks compared to host mode containers. That's not much of a concern for your average 3-tier web app but for a service intended for routing and transferring network traffic, and using constrained hardware I think favoring security and optimizing performance are a strong case to be made in favor of keeping the gateway listening address unchanged. There are plenty of legitimate reasons to run containers in host networking mode so it's unclear why it "should be avoided at all cost" but if for some reason you can't run all of your containerized components in host mode docker still makes this easily possible to "mix and match" networking strategies |
Listening on localhost will still be localhost even in host networking mode. We don't see it becoming 172.17.0.1. we will have to make all our containers host-networked to make it work. I might be wrong, don't know enough about docker networking. There might still be more ways to work around this. |
@madninja please can we reopen this issue? I don't think it's reasonable to suggest people to use host networking, and this kind of defeats the idea of docker containers. There needs to be some control of how this is exposed. Why can't it be controlled similar to the gateway listen parameter? Where we can bind it to 0.0.0.0 for example |
The API port needs to bind to 0.0.0.0 within a docker container so the service can be published.
The text was updated successfully, but these errors were encountered: