search

theia-ide / theia-apps

Theia applications examples - docker images, desktop apps, packagings
Apache License 2.0
1.04k stars 345 forks source link

Port 3000 security #456

Open jcalfee opened 3 years ago

jcalfee commented 3 years ago

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 commented 3 years ago

Hi @jcalfee ,

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

jcalfee commented 3 years ago

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.

image

marcdumais-work commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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.