55 pages about how to improve container security. @ciliumproject #BPF, best practices, @coreos clair, #apparmor https://t.co/ABiuldYA9b pic.twitter.com/61jzWxzb1Y
— :w !sudo tee % (@GianArb) June 5, 2017
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:
- How can we trust the instances part of the system itself? I mean, how can we trust a new application after a pool scale?
- All the traffic generated by the system needs to be locked. The network topology grows with the number of services that we add but that’s not a good excuse to leak on responsibility about how we do manage our network.
When you design a system you need to think about security from different points of view:
- Security needs to be efficient. This seems obvious but it’s always something to keep in mind.
- It needs to be easy to use in development mode. As we said before. If security is making things slower somebody will turn it off.
- If you are good enough to make it easy, it will be easier to enforce a secure behavior.
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
It supports 3 events:
- A - Add
- D - Delete
- C - Change
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.