Red Hat Insider: Securing containers before they take over the world
Thu 21 Jan 2016
Containers are taking over the world, now how do we we secure them? asks Josh Bressers, Security Strategist at Red Hat.
I’ve been doing security work for a very long time now, and in almost every case security wasn’t considered important until the technology or idea started to catch on in the mainstream. This is generally considered a problem, but it’s just how things work. Now that containers are taking over the world, their place in the greater security conversation is becoming more clear; it’s important to note, however, that containers aren’t special – they’re just another tool. And now that containers have caught on, it’s time to start talking about container security.
At least once a week someone assures me that when you run a workload inside a container it’s secure so there’s no need to worry about the container contents. This is not at all the reality of the situation; in fact, this attitude is dangerous. Security is just as important inside a container as it is anywhere else in your infrastructure. Containers are here, they’re being used, and they’re growing at an amazing rate. There’s no security magic though. A container is only as secure as the content running inside of it, so if you’re running a container that’s full of security vulnerabilities, the result will be the same as running a bare metal machine full of security vulnerabilities.
What’s not secure?
Container technology changes how we look at our computing environment. The basic idea is you have an image that contains just what you need that you run only when you need it. There isn’t a bunch of extra software installed and running for no reason, that could end up causing trouble later. From the security angle we call this the “attack surface”, less stuff means a smaller attack surface, more stuff, you get the idea. However, just because you’re running less stuff inside of a container, you still have to ensure that the container content isn’t out of date and full of security vulnerabilities. The size of the attack surface is irrelevant if something installed is vulnerable to serious security issues. Containers aren’t magic, they still need security updates.
There is a report from Banyan titled Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities. 30 percent is a lot. Docker Hub is the public registry that contains many containers built by a wide range of individuals and as anyone can publish content in the public registry, there’s nothing preventing new containers from shipping old insecure code. This is both a blessing and a curse. On one side, you can leverage a substantial amount of pre-existing work when you’re working with containers. On the other side, you have zero assurances that the container you just pulled doesn’t have known security vulnerabilities.
Most of these vulnerable images aren’t malicious, meaning that nobody put the vulnerable software there on purpose. Someone created the image in the past and since that image was added to the registry, new security vulnerabilities have been found. Unless someone is paying attention and has the ability to update those images, the only possible outcome is a registry that contains a large number of vulnerable images.
When a container is deployed it is common to “pull” a base container image from a registry. In the case of public registries you won’t always know what you’re dealing with, and in some cases there are known serious security issues in those container images.
I don’t want to sound like too much of a container snob here, but the container content really does matter. A number of organizations are starting to build scanners that are able to look inside a container image and report back any security vulnerabilities that might be lurking beneath the surface. The scanners are only half of the solution though, you still have to find and install the security updates.
Connect the dots
We know Linux container security is important. We know that the public registry is a bit like the wild west. And we know that containers still need security updates. So what does that mean in the big picture? How can we possibly solve this problem without having to start over?
At the end of the day, what it all comes down to is having someone you can trust supplying your container content. Containers are like any new technology. Once the new car smell wears off you have to figure out how to run your apps in a stable and secure manner, since no enterprise wants to be the next front page news story for a security breach. You can certainly choose to build and manage your own containers, but that’s not a simple solution and can be a distraction from your real goals. A far better option is to find a partner who understands container security, can deal with the problems, and let you get on with the real solutions you’re trying to build. Good security is timeless.