Docker1 has one of the most gentle learning slopes of a new technology to
enter the mainstream in a long time. A developer can get up and running in a very
short amount of time2 and begin realizing value almost immediately with
Docker, but the hard part comes when trying to secure the new technology for
use in a production like environment. Production has a much higher standard when
it comes to availability, security, and repeatability. This can lead to problems
as the differences between the development and production environment are both:
Fairly complex to replicate in a secure way: It is not feasible to pass around
the private key for your production certificate in the name of development
environment automation. On the other hand, to generate a full CA and all of the
certificates and keys required can be daunting.
Functionally quite a large delta: The difference between an insecure, non-tls
environment and an SSL one can be significant. For instance, at this exact
exact point in time it appears that Ansible does not yet support a TLS enabled
Docker host3.
In order to attack this problem, we should attempt to replicate the prod
environment when it is feasible and especially if it is easy and cheap. To this
end, let’s create the full certificate chain needed to run a secure Docker Swarm4
cluster. I think you will find that it is both easy and cheap :)
The script
This is a bash script I used5 that will output everything within the
directory it is run. It accomplishes the following things:
Creates a Certificate Authority
Creates a cert/key for Docker Swarm (supporting both client and server auth)
Generates 3 certificates for the individual Docker hosts with SAN IPs
It is required to set a config as we need to add a SAN IP Address entry to the
certificate and CSR. This is required because without it, Swarm will spit out
the following error:
Disclaimer: I am no SSL wizard and so some of the settings in the openssl.cnf
may be insecure, not needed, or even both. In addition, you can see that this is
totally insecure as
the password is in the script
the passwords are removed from the keys
many other reasons
Please don’t use these exact script or the generated certs for production use!
gen_ssl.sh
openssl.cnf
Installation
Once you have generated the TLS keys and certificates they must be installed on
the target machine. I prefer to just copy the certificate and the key files into
/etc/pki/tls/certs/ and /etc/pki/tls/private/ respectively. Once they are
installed, you can then fire up your Docker and Swarm daemons like so:
Now in order to use the Docker daemon, you will have to present a client cert
that was generated from the same CA as the certificate Docker/Swarm is using. We
have generated one here and more can be made if needed. Set the following
environment variables in order to tell the Docker client what to use for the TLS
config:
This will now enable the Docker client to communicate ‘securely’ with Docker
Swarm and Docker Swarm to communicate securely with the Docker nodes behind it.
We all like to keep our code looking as neat as possible, but sometimes you also
need to keep track of those small changes you’ve been making. A good way to ABC
(Always Be Committin’) is to work in a branch and hack your way through the
problem and then to clean up before submitting a PR.
Cut a new branch
What we are about to do here can be destructive as well as confusing. With tasks
like that, it’s always nice to have a backup and so we are going to cut a new
branch to work with off of the branch that all of the nasty more changes live
in:
git checkout -b squashed_feature
Rebase from master
This will give us a branch that we can then safely rebase from master. This
process will allow you to pick the commits you would like to squash and the ones
you would like to keep. You can do this by running:
git rebase -i master
Squash commits
If you have merged master into your branch during your development process you
will be unable to use this method. I normally will rebase my branch on master
instead of merging in, but workflows may vary. Once you begin the rebase process,
your git editor will open a file that looks like:
In this view the most recent commit will be at the top and the oldest at the
bottom. To squash all of the commits into a single one, change all the ‘pick’s
but one to ‘squash’. Note: ‘s’ will also work instead of ‘squash’
Rewrite
You want to squash these changes as if you were to remove the line itself, the
actual commit will be removed from history:
At this screen there is no need to change the commit messages. After saving and
quitting the editor, a new file will open to allow you to edit the commit
message. In that file, just remove all of the messages and replace them with the
one that you want.