By default, Docker runs through a non-networked UNIX socket. It can also optionally communicate using an HTTP socket.
If you need Docker to be reachable through the network in a safe manner, you can enable TLS by specifying the tlsverify flag and pointing Docker’s tlscacert flag to a trusted CA certificate.
In the daemon mode, it only allows connections from clients authenticated by a certificate signed by that CA. In the client mode, it only connects to servers with a certificate signed by that CA.
Advanced topic
Using TLS and managing a CA is an advanced topic. Please familiarize yourself with OpenSSL, x509, and TLS before using it in production.
Create a CA, server and client keys with OpenSSL
Note: Replace all instances of $HOST in the following example with the DNS name of your Docker daemon’s host.
First, on the Docker daemon’s host machine, generate CA private and public keys:
$ openssl genrsa -aes256 -out ca-key.pem 4096
Generating RSA private key, 4096 bit long modulus
............................................................................................................................................................................................++
........++
e is 65537 (0x10001)
Enter pass phrase for ca-key.pem:
Verifying - Enter pass phrase for ca-key.pem:
$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
Enter pass phrase for ca-key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:Queensland
Locality Name (eg, city) []:Brisbane
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Docker Inc
Organizational Unit Name (eg, section) []:Sales
Common Name (e.g. server FQDN or YOUR name) []:$HOST
Email Address []:Sven@home.org.au
Now that you have a CA, you can create a server key and certificate signing request (CSR). Make sure that “Common Name” matches the hostname you use to connect to Docker:
Note: Replace all instances of $HOST in the following example with the DNS name of your Docker daemon’s host.
$ openssl genrsa -out server-key.pem 4096
Generating RSA private key, 4096 bit long modulus
.....................................................................++
.................................................................................................++
e is 65537 (0x10001)
$ openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr
Next, we’re going to sign the public key with our CA:
Since TLS connections can be made through IP address as well as DNS name, the IP addresses need to be specified when creating the certificate. For example, to allow connections using 10.10.10.20 and 127.0.0.1:
$ echo subjectAltName = DNS:$HOST,IP:10.10.10.20,IP:127.0.0.1 >> extfile.cnf
Set the Docker daemon key’s extended usage attributes to be used only for server authentication:
$ echo extendedKeyUsage = serverAuth >> extfile.cnf
Now, generate the signed certificate:
$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \
-CAcreateserial -out server-cert.pem -extfile extfile.cnf
Signature ok
subject=/CN=your.host.com
Getting CA Private Key
Enter pass phrase for ca-key.pem:
Authorization plugins offer more fine-grained control to supplement authentication from mutual TLS. In addition to other information described in the above document, authorization plugins running on a Docker daemon receive the certificate information for connecting Docker clients.
For client authentication, create a client key and certificate signing request:
Note: For simplicity of the next couple of steps, you may perform this step on the Docker daemon’s host machine as well.
$ openssl genrsa -out key.pem 4096
Generating RSA private key, 4096 bit long modulus
.........................................................++
................++
e is 65537 (0x10001)
$ openssl req -subj '/CN=client' -new -key key.pem -out client.csr
To make the key suitable for client authentication, create a new extensions config file:
$ echo extendedKeyUsage = clientAuth > extfile-client.cnf
Now, generate the signed certificate:
$ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \
-CAcreateserial -out cert.pem -extfile extfile-client.cnf
Signature ok
subject=/CN=client
Getting CA Private Key
Enter pass phrase for ca-key.pem:
After generating cert.pem and server-cert.pem you can safely remove the two certificate signing requests and extensions config files:
$ rm -v client.csr server.csr extfile.cnf extfile-client.cnf
With a default umask of 022, your secret keys are world-readable and writable for you and your group.
To protect your keys from accidental damage, remove their write permissions. To make them only readable by you, change file modes as follows:
$ chmod -v 0400 ca-key.pem key.pem server-key.pem
Certificates can be world-readable, but you might want to remove write access to prevent accidental damage:
$ chmod -v 0444 ca.pem server-cert.pem cert.pem
Now you can make the Docker daemon only accept connections from clients providing a certificate trusted by your CA:
$ dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem \
-H=0.0.0.0:2376
To connect to Docker and validate its certificate, provide your client keys, certificates and trusted CA:
Run it on the client machine
This step should be run on your Docker client machine. As such, you need to copy your CA certificate, your server certificate, and your client certificate to that machine.
Note: Replace all instances of $HOST in the following example with the DNS name of your Docker daemon’s host.
$ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem \
-H=$HOST:2376 version
Note: Docker over TLS should run on TCP port 2376.
Warning: As shown in the example above, you don’t need to run the docker client with sudo or the docker group when you use certificate authentication. That means anyone with the keys can give any instructions to your Docker daemon, giving them root access to the machine hosting the daemon. Guard these keys as you would a root password!
Tyk API Gateway
Tyk is a lightweight, open-source API Gateway and Management Platform enables you to control who accesses your API, when they access it and how they access it. Tyk will also record detailed analytics on how your users are interacting with your API and when things go wrong.
What is an API Gateway?
An API Gateway sits in front of your application(s) and manages the heavy lifting of authorization, access control and throughput limiting to your services. Ideally, it should mean that you can focus on creating services instead of implementing management infrastructure. For example, if you have written a really awesome web service that provides geolocation data for all the cats in NYC, and you want to make it public, integrating an API gateway is a faster, more secure route than writing your own authorization middleware.
Key Features of Tyk
Tyk offers powerful, yet lightweight features that allow fine-grained control over your API ecosystem.
- RESTFul API - Full programmatic access to the internals makes it easy to manage your API users, keys and Api Configuration from within your systems
- Multiple access protocols - Out of the box, Tyk supports Token-based, HMAC Signed, Basic Auth and Keyless access methods
- Rate Limiting - Easily rate limit your API users, rate limiting is granular and can be applied on a per-key basis
- Quotas - Enforce usage quotas on users to manage capacity or charge for tiered access
- Granular Access Control - Grant API access on a version by version basis, grant keys access to multiple API's or just a single version
- Key Expiry - Control how long keys are valid for
- API Versioning - API Versions can be easily set and deprecated at a specific time and date
- Blacklist/Whitelist/Ignored endpoint access - Enforce strict security models on a version-by-version basis to your access points
- Analytics logging - Record detailed usage data on who is using your API's (raw data only)
- Webhooks - Trigger webhooks against events such as Quota Violations and Authentication failures
- IP Whitelisting - Block access to non-trusted IP addresses for more secure interactions
- Zero downtime restarts - Tyk configurations can be altered dynamically and the service restarted without affecting any active request
Tyk is written in Go, which makes it fast and easy to set up. Its only dependencies are a Mongo database (for analytics) and Redis, though it can be deployed without either (not recommended).
Docker Socket Proxy
What?
This is a security-enhanced proxy for the Docker Socket.
Why?
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.
How?
We use the official Alpine-based HAProxy image with a small configuration file.
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.