Port 3000 security

[jcalfee]

For security, probably good to mention:

bind it to localhost, like this:

    docker run -p 127.0.0.1:3000:3000

https://stackoverflow.com/a/22100687/766233

[marcdumais-work]

Hi @jcalfee ,

Thanks for the suggestion. Would you care submitting a PR e.g. where you update the README examples as per above?

[jcalfee]

localhost will not work anymore. Its going to have to be 127.0.0.1 .. It works for me on Linux. I don't know about Mac and PowerShell.

[marcdumais-work]

localhost will not work anymore. Its going to have to be 127.0.0.1 .. It works for me on Linux. I don't know about Mac and PowerShell.

Hi @jcalfee Thinking a bit more, given the wide array of potential use-cases for contenarized Theia apps, maybe this possibility should only be mentioned (as you originally suggested), rather than applied across the board? e.g. something like:

If you intend to run and access the container only locally, you can start it like so:
docker run -it --init -p 127.0.0.1:3000:3000 ...

[jcalfee]

I guess if your running behind a proxy and have a password on the proxy already then leaving it open is safer. But is seems like the typical use-case for docker run for an IDE is to just to run it on the local host and have no external access. If that is the typical case, then binding it to 127.0.0.1 would make a reasonable default. Unless you can think of a case that it would cause a lot of confusion for the new user.

[jcalfee]

Another thing to consider .. If projects involve potentially many ports --network host might be a very practical option to use for Theia's docker container. This exposes unrelated ports to Theia, but I can't see that being a big security issue. Most other projects have port security (password, etc) anyways and are designed with running on the host's network anyways. Docker, however, ignores -p if --network host is used (see Note in docker network). So it would be useful to have IP binding (like 127.0.0.1) in the Theia process itself.

[marcdumais-work]

@jcalfee thank you for the thoughtful arguments. I agree that probably the local use-case is the most popular vs a more intricate setup with a proxy in front to handle such things as authentication. I also agree that it's desirable in most cases to limit remote access if not needed.

OTOH we do not aim to have full-fledged products in this repo, but rather a set of interesting Theia-based examples that can inspire various use-cases. I'm a bit concerned that if we "child-proof" the examples, it will take-away from the main aim of the repository. Perhaps what would be really desirable is to have a separate, productified version of a docker image that contains a Theia application.

@vince-fugnitto @dukengn WDYT?

[vince-fugnitto]

OTOH we do not aim to have full-fledged products in this repo, but rather a set of interesting Theia-based examples that can inspire various use-cases

I agree, the repository is mainly used for test purposes, and as an example for others to reference and developer their own production-ready docker images (as expressed in the readme).

Perhaps what would be really desirable is to have a separate, productified version of a docker image that contains a Theia application.

It can be useful, unfortunately I do not think we have the bandwidth to support such a productified image which others can reuse reliably. It's one thing to provide an example in a pull-request but the maintenance and support for such an image may be out of scope of this repository (at the moment we have a best effort to update the images, make them build and update them).

[jcalfee]

Usually something like this is just an environment variable passed to Docker that is picked up in code like process.env.THEIA_PORT where that can have a value like THEIA_PORT=127.0.0.1:3000 then nodejs should take care of the rest (that is typically how socket layers work). That is just for your benefit, only do it if you find that useful in your own setup. But I do find --network host really helpful, no need to restart Theia or worry about what ports you might want to access in advanced or worry about removing ports you don't need anymore.