Managing Docker Authentication
Once you’ve chosen how you want to set up your development environment, the next consideration to think about is Docker authentication. Docker typically is set up with a set of certificates to enable remote access of a Docker client using Transport Layer Security (TLS) over port 2376. You can find instructions on how to create certificates and configure the Docker daemon at http://bit.ly/ch4certs. As part of the certificate creation, you will end up with three certificates: cert.pem, key.pem, and ca.pem, all of which should be added to your user folder “~/.docker for Mac” or “C:Users<username>.docker” on Windows as discussed in Chapter 2, “Containers on Azure Basics.”
One common issue that will arise is the need to manage multiple certificates. For example, you likely will have different certificates for your local development environment, CI, or staging environments. Similarly, if you’re doing development across multiple teams, for example, developing microservices for the finance and human resources departments, each team likely has a different set of certs they use for their environments. One simple way of organizing certs is to have all certs under your .docker machines directory, with each environment as a separate subfolder with its own set of keys. You can then use the DOCKER_CERT_PATH environment variable to set the keys for each environment like the dev environment for finance:
set DOCKER_CERT_PATH=c:users<username>.dockermachinemachines
finance-dev
or on a Mac:
export DOCKER_CERT_PATH=~/.docker/machine/machines/finance-dev
As each Docker host (virtual machine) needs its own set of keys, you want to make sure you have an easy way to manage a set of authentication keys across multiple developers and multiple virtual machines. Remember not to include your Docker certs in your source control system, as by doing that, you are effectively giving full trust and control to anyone who has access to your source control system. Further, hackers can use automated sniffers that recursively search source control systems for passwords and certificates, so instead of only gaining access to your source control system, hackers would then be able to fully control your deployment servers.
• For local development, use the built-in Docker keys that are unique to each developer. These are stored in the default directory, located at C:users<username>.dockermachinemachinesdefault or ~./docker/machine/machines/default on a Mac.
• For a shared development environment, developers typically share a set of Docker keys across the team as developers require the need to directly manage and monitor containers, including viewing logs, stats, and performance.
• Promotion of source code between environments, like dev to staging or production is typically handled by release management tools like Atlassian, or Visual Studio Team Services using an automated process. Docker certificates in staging and production are typically managed by your ops team instead of developers.