How can I deal with security updates in my docker containers?

Question

We want to avoid including "yum update" within the dockerfiile, as it could generate a different container based on when the docker images is built, but obviously this could pose some security problems if a base system needs to be updated. Is the best option really to have an organization wide base system image and update that? The issue there would be that it would require rebuilding and deployment of all applications across the entire organization every time a security update is applied.

An alterative that seems a bit out there for me, would be to simply just ignore security updates within the container and only worry about them on the host machine. The thought process here would be that for an attacker to get into a container, there would need to be a vulnerability on the host machine, another vulnerability within docker-engine to get into the container, and then an additional vulnerability to exploit something within the container, which seems like an incredibly unlikely series of events. With the introduction of user namespacing and seccomp profiles, this seems to further reduce the risk.

Anyway, how can I deal with security updates within the containers, with minimal impact to the CI/CD pipeline, or ideally not having to redeploy the entire infrastructure every so often?

Answer 1

You could lessen the unrepeatability of builds by introducing an intermediate update layer.

Create an image like:

FROM centos:latest
RUN yum update -y

Build the image, tag it and push it. Now your builds won't change unless you decide to change them.

You can either either point your other Dockerfiles to myimage:latest to get automatic updates once you decide to do so or point to a specific release.

The way I have setup my CI system is that a successful (manual) build of the base image with updates triggers a build of any images that depend on it.

A security issue gets reported? Check that an updated package is available or do a temporary fix in the Dockerfile. Trigger a build. In a while you will have fixed versions of all your apps ready to be deployed.

Answer 2

Most major distributions will frequently release a new base image which includes the latest critical updates and security fixes as necessary. This means that you can simply pull the latest base image to get those fixes and rebuild your image.

But also since your containers are using yum, you can leverage yum to control which packages you update. Yum allows you to set a release version so you can pin your updates to a specific OS release.

For example, if you're using RHEL 7.2, you might have a Dockerfile which looks something like:

FROM rhel:7.2
RUN echo "7.2" > /etc/yum/vars/releasever
RUN yum update -y && yum clean all

This ensures that you will stay on RHEL 7.2 and only receive critical package updates, even when you do a full yum update.

For more info about available yum variables or other configuration options, just look at the 'yum.conf' man page.

Also, if you need finer grained control of updates, you can check out the 'yum-plugin-versionlock' package, but that's more than likely overkill for your needs.