Global network considerations

Quick overview

External network access

Only web servers need to be reachable by end users. User access should go via an HTTPS proxy, proxying/load balancing request to GoDocker web servers. Web servers need read access to the shared directory.

Firewalls should only leave HTTPS port (443) open to web servers.

If go-d-ftp is used, then FTP port (according to configuration) should also be opened. FTP needs read and write access to the shared directory

For interactive jobs, users can connect via SSH to the container. To do so, it is advised to setup a SSH gateway server where user will connect before jumping to the container. This gateway would be in a DMZ and acting only as SSH frontend. SSH Gateway should limit outbound connection to cluster nodes and in defined port range.

User =(HTTPS) ==> Web proxy =(HTTP) ===> Web servers

        =(FTP)==>  FTP server

        =(SSH)==> SSH Gateway =(SSH)==> Nodes with containers

If user opens a port in a container, port will be mapped to a node port within allowed port range. As cluster nodes do not usually have public IP addresses, port is not directly reachable. User may need to connect to SSH gateway and locally contact the container port (via a browser, application, ...)

Internal network access

Databases and status handlers (etcd, consul, ...) should have limited access. Only web server, ftp, scheduler and watcher nodes should have inbound access.

Scheduler and watcher nodes needs read/write access to shared directory.

Scheduler and watcher nodes needs inbound connection access to the selected executor (mesos master/slaves, swarm, kubernetes master).

Web server processes must have access to cluster nodes (to query cAdvisor or mesos slaves)

End users must not have direct access (ssh) to the cluster nodes.

Security and network considerations

Some considerations are to be taken into account when using Go-Docker, mainly due to Docker own security considerations.

Root access

Application can allow (configuration parameter) the user to access the container as root (interactive or batch). Allowing this may present some risks because the host kernel is used to run the container. You should trust your users to allow such access. You can learn more about this here:https://docs.docker.com/articles/security/.

Container images should also be selected carefully. If you allow users to use any image, they may gain root access in the container due to sudo configuration in the container, or default root passwords.

A mitigation could be to allow images from a specific private registry where you have control on images.

Network

Go-Docker will mount, if requested, user home directories etc... in the container. Usually, those directories are NFS shares on the host system. In the container, those mounts will appear as a local file system. Shared directories (common data etc...) should be set in read only mode, specifically if user can have root access (but even if not allowed, it is advised to do so to prevent any privileged escalation).

Containers are executed in "bridge" network mode (the default Docker one or one you created and assigned to Docker). This means that containers will run (from a network point fo view) with a local IP address behind the bridge. You should take care to prevent access to your local network from this bridge, and allow only external network access (internet) or allowed services (smtp gateway etc.), if needed of course. If no network is needed, then only set in configuration network_disabled = True.

This filtering can be managed by local iptables rules in the Docker filter chain. More info on Docket networking is available here https://docs.docker.com/articles/networking/.

Password/Credentials/...

Sometimes, a script may need a database password to run. As scripts are stored in internal database, it is not secured to put clear passwords in the submitted shell commands. Furthermore, it can be quite boring to put the same identifiers again and again in scripts.

We recommend storing needed credentials in an environement shell script in the home directory (if you can mount it, or any accessible personal shared directory) and load this file at the start of the bash script.

Example go-docker script, with the home directory in requested volumes:

#!/bin/bash

.  $GODOCKER_HOME/.my_env_script_with_passwords
connect_with_credentials.sh $MYUSER -p$MYPASSWORD

And in your home directory ".my_env_script_with_passwords" file:

export MYUSER="xyz"
export MYPASSWORD="123456"