Container security and immutability

05 Jun 2017 · Four minute read · on Gianluca's blog

Security is a fascinating topic. It’s part of every aspect of a system. From your email server to the HTTP body validation of your API system.

It’s also a very human centric topic. You can use the most stronger security approaches but if your rules are too hard to follow or too complicated to implement the end users or your colleagues will become the perfect breach to be exploited by bad people.

In distributed systems there are interesting challenges like:

When you design a system you need to think about security from different points of view:

All this concepts are well applied in all different projects built by the Docker Community. Notary, swarmkit are just a few examples but if you think about the update framework (TUF) and the whole set of things happening behind every docker push and pull command you suddenly see a great example on how to make complicated things really easy to use.

I published an ebook that you can download for free here. It contains ~55 pages about Container and Docker Security. In this article I will share one of the concept expressed in that book, Immutability.

Docker containers are in fact immutable. This means that a running container never changes because in case you need to update it, the best practice is to create a new container with the updated version of your application and delete the old one.

This aspect is important from different point of views.

Immutability applied to deploy is a big challenge because it opens the door to a very different set of release strategies like blue green deployment or canary releases. Immutability also lowers rollback times because you can probably keep the old version running for a little longer and switch traffic in case of problems.

It’s also a plus from a scalability and stability point of view. For each deploy you are in fact using provisioning scripts and build tools to package and release a new version of your application. You are creating new nodes to replace the old ones that means that you are focused on provisioning and configuration management. You are justifying all the effort spent to implement infrastructure as code.

It matters also for security because you will have a fresh container after each update and in the case of a vulnerability or injection they will be cleaned during the update.

You have also an instrument to analyse the attacked container with the command docker diff This command shows the differences in the file system.

It supports 3 events:

In case of attack, you can commit the attacked container to analyse it later and replace it with the original image.

This flow is interesting but if you know that your application does not need to modify the file system you can use –read-only parameters to make the fs read only or you can share a volume with the ro suffix -v PWD:/data:ro.

Docker can’t fix the security issues for you, if your application can be attacked by a code injection then you need to fix your app but Docker offers a few utilities to make life hard for an hacker and to allow you to have more control over your environment.

During this chapter we covered some practices and tools that you can follow or use to build a safe environment.

In general, you need to close your application in an environment that provides only what you need and what you know.

If your distribution or your container has something that you don’t have under your control or it is unused then it is a good idea remove these dark points.

That’s all. Immutability is not free and it requires to keep all the tools and processes involved in deploy, packaging up to speed because all your production environment depends on these tools. But it’s an important piece of the puzzle. To read more about tools like Cilium, CoreOS Clair, best practices about registry and images you can download the pdf Play Safe with Docker and Container Security.

Something weird with this website? Let me know.