If you would like to read the other parts in this article series please go to:
- Containerization Proliferation: The Docker Effect (Part 1)
- Containerization Proliferation: The Docker Effect (Part 2)
- Containerization Proliferation: The Docker Effect (Part 3)
- Containerization Proliferation: The Docker Effect (Part 4)
- Containerization Proliferation: The Docker Effect (Part 6)
Introduction
In Part 1 of this multi-part article series, I briefly explained what containers are, some benefits of using containers and the scenarios in which they aren’t the best choice, and some generalities about how they work. In Part 2, we discussed popular container solutions, beginning with Docker. In Part 3, we started talking about container security in general and Docker security in particular. Because securing Docker also depends on securing the underlying host OS, in Part 4 we addressed how you can harden the Linux host using SELinux, AppArmor, and Grsec, which are general Linux security mechanisms.
Docker Content Trust
In the summer of 2015, the folks over at Docker recognized that they had the same problem as cloud vendors: people were excited over what they had to offer and wanted to use it, but potential customers were hesitant because of their concerns about security. That spurred them to focus on improving security in the v1.8 release of Docker.
Docker container images can come from one of two places: from a disk or from a remote registry. There are a number of certified official repositories including Docker’s own Docker Hub and those run by Oracle, Canonical, RedHat and other software vendors/Docker partners. Companies can run their own registries, as well. Communications between Docker and the registries are encrypted with TLS and the default is to require certificates trusted by the public PKI. Companies’ internal CA root certificates can be added to the certificate store as well.
Docker Content Trust (DCT) is designed to control the software that runs in your Docker environment by verifying the source of your Docker images via a digital signature, and protect you from Man-in-the-Middle (MITM) attacks, Replay attacks, and key compromise. It’s based on The Update Framework (UTF) and is a part of the Docker engine.
DCT was released as an optional feature, but once a user enables it there is no big learning curve. Developers don’t have to master any new commands because it will be automatically integrated into their work and users don’t have to do anything differently to run the images. DCT uses a “trust on first use” model whereby the establishment of trust between user and publisher occurs the first time a user uses a particular image. The trust relationship process is done over HTTPS.
A Public Key Infrastructure (PKI) is the basis of DCT security. The image publisher’s private key is used by the Docker engine to sign the image before it’s uploaded to a remote registry, and then the public key is used to authenticate that the image hasn’t been tampered with. DCT uses different cryptographic keys in this process, including what it calls a tagging key, an offline key (root) and a timestamp key. Using multiple keys makes it possible to recover when a key is compromised, and allows publishers to remove compromised keys or rotate keys to protect against undetected compromises.
Anytime anyone uploads content to a repository or removes content from one, the tagging key comes into play. It’s stored online, so it’s vulnerable, but each separate repository has its own unique key, and the root key can generate new tagging keys. The purpose of the timestamp key is to prevent the running of content for which the certificate has expired.
Publishers who want to sign their content collections can download Notary, which is a tool that’s integrated into DCT for publishing and verifying content.
Note:
When you’re using Docker Content Trust, the keys are literally the “key” to your security, so it’s important to back them up. You can save the root key – which is used when you create new repository keys – in a USB key or some other secure location. Keeping the root key offline keeps it secure and allows you to confidently create a new repository key if one is compromised, and this renders earlier versions of the repository key invalid.
Augmenting Docker security with third party solutions
As we’ve seen in previous installments, Docker containerization provides some security benefits but does not provide the level of isolation that traditional virtualization does, and presents some security challenges of its own. In the software world, where there’s a need, there is usually a company (or more than one) that recognizes the opportunity and fills in the gap. When it comes to Docker security, a number of third party solutions have appeared to help make containerization more safe and secure.
Twistlock
The third party Docker security solution with which I’m most familiar is Twistlock, which is a set of vulnerability management, access control and runtime defense technologies that are specifically built to protect containers and their contents. Full disclosure: one of the founders and CEO of the company is a long-time friend who formerly worked with my husband at Microsoft on Windows Server and security products. Thus I’m familiar with his expertise and breadth of knowledge. The co-founder and CTO are also former Microsoft employees.
Twistlock addresses the security issues that we’ve discussed earlier in this series, beginning with the task of tracking and remediating vulnerabilities both in the Linux layer and in the applications that run in your containers. The Twistlock software can container images regardless of where they reside (on a workstation or production server or in the registries) and relentlessly searches for security flaws and vulnerable components and configurations, then sends the results of those searches to the console where admins can use the information to close the gaps.
Twistlock’s reports go into detail about the findings, letting you know exactly which libraries, packages and frameworks contain which vulnerabilities, in which containers, and can even provide you with instructions for addressing the problems. Twistlock is integrated with the CVE databases so you don’t have to wonder whether a particular reported vulnerability matches up with a particular CVE number.
The “smart runtime defense” is another feature in Twistlock’s arsenal that is designed to ferret out anomalies in runtime, using automatic profiling policies that are created by fingerprinting malicious behaviors, analyzing user access, scanning images during development and profiling system calls. Because they are generated automatically, using this feature doesn’t involve a lot of extra work on the part of the IT professional.
That doesn’t mean you have no control, though. Runtime protection includes policy templates and best practices and an interface through which you can define what settings you approve as well as certified images and approved processes. Twistlock can enforce these policies on all of your containers. Other features include building profiles from the network activity of your containers so as to identify when behavior deviates from the norm.
Detection of policy violations results in more than just a log entry or a notification sent to admins (unless that’s all you want). Twistlock can spring into action to block users from accessing containers or can even shut down containers that have been compromised.
To accomplish all this, Twistlock “Defenders” run as privileged containers on host OS, alongside the application containers. It is the Defender that monitors runtime behavior, identifies malicious behavior, alerts you to the situation and takes action to fix the problem.
In addition to these protections against exploits, misconfigurations and compromises, Twistlock has access control technology that lets you impose controls on which and how users access Docker resources in the enterprise, integrating with LDAP directories (including Microsoft’s Active Directory, of course). The benefit of this is that you can apply access policies to container resources for AD users and groups, and you can make exceptions to policies when needed, as well. There’s no steep learning curve, either. You can use or modify existing policies or create new ones, so there is plenty of flexibility and the capability to address special scenarios custom-made for your particular environment.
You know that when it comes to IT security today and particularly for purposes of proving compliance with government and industry regulations, it’s not enough to have strong controls – it’s also essential that you be able to show documentation of your security measures. Twistlock also gives you user access audit trails that can be exported to logging solutions (or to forensics devices for investigation of security incidents). The information is detailed and includes identities and their actions and services requested along with timestamps.
Summary
Making Docker containers more secure has gotten easier, thanks to new security mechanisms built into recent versions of Docker itself along with the advent of third party solutions that can take Docker security to a higher level. In this, Part 5 of our look at the container phenomenon, we took a look at Docker Content Trust (DCT) and at Twistlock’s Docker security technologies.
Next time, in the 6th installment of the series, we’ll talk a little about Kubernetes, Google’s container management solution, and Microsoft’s entries into this space: Windows Server Containers and Hyper-V Containers.
If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
