Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

codenvy/cli connect to docker on TLS

See original GitHub issue

Issue Description

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.

Issue Analytics

State:
Created 6 years ago
Comments:27 (19 by maintainers)

Top GitHub Comments

2reactions

riuvshincommented, Mar 27, 2017

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?

1reaction

skryzhnycommented, Mar 27, 2017

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.

Top Results From Across the Web

Protect the Docker daemon socket - Docker Documentation

Protect the Docker daemon socket. By default, Docker runs through a non-networked UNIX socket. It can also optionally communicate using SSH or a...

Set Up Docker with TLS: /Documentation - LabKey Support

Run with devmode=true. Otherwise a secure connection is required, whether the docker server is local or remote. Installation Instructions for Docker Daemon.

Develop on a remote Docker host - Visual Studio Code

Follow the quick start for the Remote - SSH extension to connect to a host and open a folder there. Use the Dev...

Use Docker to build Docker images - GitLab Docs

Introduced in GitLab Runner 11.11. The Docker daemon supports connections over TLS. In Docker 19.03.12 and later, TLS is the default.

Connection to daemon using HTTPS — docker-py 1.3.1 ...

Authenticate server based on given CA¶. tls_config = docker.tls.TLSConfig( ...