In the course of Twistlock’s relatively brief corporate life, we have talked with many enterprises, startups, OEMs, developers, consultants, and I guess a few other folks as well.  There’s a huge amount of excitement and passion about containers and the benefits they’re providing to all of these stakeholders.  At the same time, there’s a general agreement that the security model for containers is still evolving and most organizations don’t have a good handle on how to meet all their container security threats requirements while still getting all the benefits of the container computing model.

It’s particularly interesting to see how much of the container security threats discussion revolves around the segregation capabilities of containers versus VMs.  I feel this has been burdening me for a while so I’ll just say it:

VM segregation vs container segregation is not the most problematic security issue with containers

There,  I said it.

I’m sorry to disappoint anyone who reads this who might think differently; segregation is a sexy topic, everyone is aware of it, but the way most folks resolve it is by avoiding multi-tenancy.  Avoiding multi-tenancy doesn’t mean running only one container on a given VM.  It just means you don’t mix containers of different applications on the same host operating system (which may or not be within a VM), period.

What is the biggest security concern might you ask?  Again, based on many conversations we’re having with customers, we believe the answer as of now is actually two areas:

Security Policy Enforcement

This means that because containers are super portable, they contains tons of little pieces that used to be traditionally owned by operations teams, but are now owned by the dev team.  While this enables continuous deployment and overall better results it can also create a huge container security threat.  Consider, for example, a scenario where a developer requires access to privileged ports or local storage.  In a traditional operating model, the developer would probably work with the operations team to describe what they need and the operations team could apply the right security tools, such as running the app in specific virtual network that’s monitored by an IDS.  In this new container world, though, the operations team often has no knowledge about what the containers are actually doing while in their environment.

Vulnerability Detection Is a Major Issue With Containers & Docker

Containers, by design, are ‘thin’, which means they only contain the minimum necessary elements to run an app.  This has great benefits, like runtime efficiency, simpler deployment, and reduced test surface area.  However, it also means that they no longer have the sames kinds of host monitoring and security agents as on a more traditional guest OS.  In practice, this can often result in having some vulnerable version of Java, OpenSSL, or other component in one of the gazillion containers you have running and not know about it.  Because containers are designed to be re-packaged and re-deployed, rather than updated in place, the task to keep them up to date is no longer really manageable by operations teams because their standard tools aren’t available.  Instead, it’s up to the developers to stay aware of vulnerabilities and repackage apps as needed.  Of course, developers are pretty busy too, so the risk of flaws not be addressed rises significantly when the traditional tools and processes in place are no longer applicable.

At Twistlock, we’ve worked hard to address both of these problems through declarative, software driven approach.  Because we’ve built our product specifically for containers, we’re well aligned with both the technology itself but also the larger operational shift that containers and devops bring.  For example, we allow customers to declare their security policies (e.g. container hardening, Docker hardening, requirements to use hypervisors) through a simple graphical UI that our software then executes across all the places your containers run and throughout the dev lifecycle.  So, your policies are in place from the very first time a developer packages their app as a container, through its runtime in your production environment.

From a vulnerability management standpoint, we provide organizations with a consolidated intelligence stream composed of CVE information from commercial providers, open source projects, and governmental sources.  This stream covers not just the threats to Docker and the host, but also to distribution components, shared libraries, and Java, Python, and Ruby components.  We use this threat feed to allow customers to create vulnerability management policies that are enforced across their environment.  That’s a hugely important capability when you’re operating lots of containers at scale so we’ll cover it in more detail in a future post.

What’s Next?

← Back to All Posts Next Post →