|javieryanez a07d4ae4d9||9 months ago|
|hooks||9 months ago|
|Dockerfile||9 months ago|
|LICENSE.txt||3 years ago|
|README.md||9 months ago|
|haproxy.cfg||9 months ago|
This is a security-enhanced proxy for the Docker Socket.
Giving access to your Docker socket could mean giving root access to your host, or even to your whole swarm, but some services require hooking into that socket to react to events, etc. Using this proxy lets you block anything you consider those services should not do.
It blocks access to the Docker socket API according to the environment
variables you set. It returns a
HTTP 403 Forbidden status for those dangerous
requests that should never happen.
Run the API proxy (
--privileged flag is required here because it connects with the docker socket, which is a privileged connection in some SELinux/AppArmor contexts and would get locked otherwise):
$ docker container run \ -d --privileged \ --name dockerproxy \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 127.0.0.1:2375:2375 \ tecnativa/docker-socket-proxy
Connect your local docker client to that socket:
$ export DOCKER_HOST=tcp://localhost
You can see the docker version:
$ docker version Client: Version: 17.03.1-ce API version: 1.27 Go version: go1.7.5 Git commit: c6d412e Built: Mon Mar 27 17:14:43 2017 OS/Arch: linux/amd64 Server: Version: 17.03.1-ce API version: 1.27 (minimum version 1.12) Go version: go1.7.5 Git commit: c6d412e Built: Mon Mar 27 17:14:43 2017 OS/Arch: linux/amd64 Experimental: false
You cannot see running containers:
$ docker container ls Error response from daemon: <html><body><h1>403 Forbidden</h1> Request forbidden by administrative rules. </body></html>
The same will happen to any containers that use this proxy's
2375 port to
access the Docker socket API.
You grant and revoke access to certain features of the Docker API through environment variables.
Normally the variables match the URL prefix (i.e.
AUTH blocks access to
/auth/* parts of the API, etc.).
Possible values for these variables:
0to revoke access.
1to grant access.
These API sections are mostly harmless and almost required for any service that uses the API, so they are granted by default.
These API sections are considered security-critical, and thus access is revoked by default. Maximum caution when enabling these.
POST: When disabled, only
HEADoperations are allowed, meaning any section of the API is read-only.
You will possibly need to grant access to some of these API sections, which are not so extremely critical but can expose some information that your service does not need.
You can set the logging level or severity level of the messages to be logged with the
LOG_LEVEL. Defaul value is info. Possible values are: debug,
info, notice, warning, err, crit, alert and emerg.
Please send any feedback (issues, questions) to the issue tracker.