Global network considerations
TODO
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"