Skip to content
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

Security #66

Closed
Vanuan opened this issue May 7, 2017 · 10 comments
Closed

Security #66

Vanuan opened this issue May 7, 2017 · 10 comments

Comments

@Vanuan
Copy link
Contributor

Vanuan commented May 7, 2017

How secure is this for running in production?

It looks like it exposes the Docker Remote API to the world. Is it correct?

@Vanuan
Copy link
Contributor Author

Vanuan commented May 7, 2017

Well, even if you're running this locally on a computer connected directly to the internet (e.g. ipv6) and using the mapping suggested in readme: 8080:8080 you're under threat.

@justintime4tea
Copy link

If you're running locally wouldn't a remote client need to traverse NAT to reach your local machine? If you're running local and don't have your "public facing" router forwarding traffic internally I think you'd be ok... Though I may be misunderstanding something. If you're running it remotely you could bind the visualizers port 8080 to the IP of a tun adapter and VPN to the remote machine to ensure the visualizer access is restricted to clients connected via the VPN network.

@Vanuan
Copy link
Contributor Author

Vanuan commented May 10, 2017

@justintime4tea

traverse NAT

Some internet providers don't use NAT and provide a real IP address.
This is especially true if ipv6 is used where each device is directly exposed to the internet.

So TL;DR: never run this on a computer exposed to the internet. Is that correct?

@Vanuan
Copy link
Contributor Author

Vanuan commented May 10, 2017

Well, even when you're in company's VPN network, coworker can own your computer which might be a bad joke.

@nsmag
Copy link

nsmag commented Jul 5, 2017

what If we just expose the endpoint that trigger all Docker Remote API queries on server-side instead of directly expose the Docker Remote API endpoint?

@oppianmatt
Copy link

yep running this on production isn't good since by default docker will expose the port bypassing any firewall rules

@knutole
Copy link

knutole commented Aug 9, 2017

How can this be run safely in production? What should be changed?

@ManoMarks
Copy link
Contributor

Let's keep in mind this is meant to be a sample app, not an app you would run in production. It initially was devised for visualization demos at DockerCon EU in 2015, and used again at DockerCon Seattle in 2016. So yes, it is not meant to be run in production.

If you wanted to run it in production you can Protect the Docker daemon socket. It's much more cumbersome to do so.

@ManoMarks
Copy link
Contributor

Warning added in #67

@oppianmatt
Copy link

oppianmatt commented Aug 16, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants