Docker Images, Security, and the New Maintenance Cycle

Container management and development of a process towards keeping Docker images secure may seem like a daunting task, especially at scale. Stale images lead to security vulnerablities, and this is a very real concern when administrators can let containers run for weeks at a time without updates.

Like most early adopters, we struggled for some time to adjust our concept of a maintenance cycle within a container-driven paradigm. However, over time, we’ve evolved a moderately sane method for keeping our containers up to date and secure:

Develop Comprehensive Tests for the Container


Provide test coverage for your application, and include them in the application repository. A discussion of test writing is far out of scope for this post. Some discussions and resources, some relating to Drupal:

Testing Tools

Ensure that the image can (optionally) be launched with the tools and means to test itself. To avoid polluting production images with testing tools and libraries, we allow an environment variable to control the installation of testing tools when launching the container.

Build the Image and Run Tests

Once tests are developed, have your CI service (Travis) build the image and run the tests.

Build/Push Image to Repo On Success

Upon successful testing, configure the CI service to trigger a build and push to the image repository. For our public images, this is DockerHub. For our private images, this is the Amazon EC2 Container Registry.

Configure cron for builds

Most CI services offer cron based triggering. Travis provides repository cronjobs upon request. Triggering a nightly rebuild and test will pull in security fixes automatically, and re-test the image using those new changes.

Deploy Rolling Updates for Instance Nodes

In low-traffic periods, update the running containers with the new images stored in the repository. How this occurs depends entirely on your infrstructure and setup.

Post Tags:


comments powered by Disqus