codenvy/cli connect to docker on TLS

Codenvy version: 5.5.0

Issue

By default codenvy/cli will open Docker port 23750 and any user having access to it will have root-like access to this machine. This means anyone on the internet if the port is exposed or anyone on the network if not. Docker has a mechanism to secure socket connections and codenvy/cli may use it, or offer to use it during install, and warn other wise.

Background:

For Codenvy on-premise users, the simplest (and likely most common) path is using docker ... codenvy/cli start on a single machine (especially it’s limited to 3 users most people won’t need more than one and don’t have more than one). It also means that this machine is likely to have rights to deploy websites to production.

It’s say that the first and simplest step is to warn, as blocking that port may be seen as secure enough for most users. The second may be to encrypt by default.

See also https://github.com/codenvy/codenvy/issues/1944#issuecomment-287602237

[riuvshin]

so i did some investigation on this and figured that we can’t get rid of exposing 23750 port in socat container because it will break all in one (default) functionality where we using same instance for running workspaces. However we don’t need it when we using external nodes for running workspaces (production mode) in this case we don’t run workspaces on master node so I can make this expose configurable but enabled by default, which will allow to disable expose in production mode. WDYT guys?

[skryzhny]

I’m not really happy with solution you proposes. We need to get rid of this exposure, as it really bad for users who’s trying codenvy on non-VM. Maybe we need add logic that translates internal ‘socat’ address to external one when presenting to user’s browser. So we can get rid of exposure at all. Or somehow, probably with extra-hosts allow access to socat port published to 127.0.0.1 so it isn’t accessible from outside of a host. However second option requires use of DNS name, not IP. We discussed such approach even for external nodes, as sometime WorkspaceNodes may have different DNS/IP when accessed internally (codenvy software) and externally (user’s browser). It would allow internally communicate with secured internal net while presenting to user externally accessible part of infrastructure.