How secure are containers? Not very, according to open source company Red Hat, which has published a blog post blasting the container ecosystem for lacking good security processes. Here’s a synopsis of what Red Hat has to say about container security, and some perspective on it.
Red Hat seized upon a recently disclosed vulnerability in glibc, the main open source C programming library, to bring up the issue of container security. The code flaw in glibc enables buffer overflow attacks.
The potential impact of the glibc vulnerability (which open source software companies are now patching) is in no way limited to containers. It could affect any platform that relies on glibc — which means pretty much anything that runs Linux.
Still, Red Hat emphasized that security issues like this place containers at particular risk. That is because container vendors, like Docker, “aren’t actually in control of the containers that their users are deploying, let alone the underlying operating system powering these container deployments,” Red Hat says. “This means that while they are offering the tools for you to find these problems, when it comes to actual fixes, they may not have the expertise, capabilities or the ownership to actually fix the problem.”
And if you think that running security scanners on your containers will keep you safe, think again, Red Hat says — mostly because scanners are only useful for identifying security problems, not actually fixing them. “Container scanners are a paper tiger,” according to Red Hat. “Sure, they look fierce and they’ll roar to let you know that trouble’s on the way, but they fold like the paper that they’re made out of when you need them to do more than just…well…scan.”
Not surprisingly, Red Hat suggests that enterprises can only safely deploy containers when they adopt an integrated container solution, like the company’s Red Hat Enterprise Linux Atomic Host platform. An integrated solution means container certification, security scanning and software patches — not to mention the underlying host operating system — come built in. You get much more than just the container infrastructure itself.
Of course, you also have to pay for this service. In contrast, you could set up Docker (or CoreOS, or whatever container solution you prefer) yourself for free.
So, do Red Hat’s warnings about container security reflect a mere marketing pitch designed to convince companies to pay for container solutions instead of choosing free routes? Or is there a more significant message here?
The answer is that there surely is plenty of value — from not only a security perspective but also in terms of ease of use and reliability — in adopting an integrated container solution like Red Hat’s. It’s also true that, given the newness of containers, there is good reason to be more cautious about potential container security issues than there is regarding, say, virtual servers. The latter have been around for much longer, and benefit from much better security tools and protocols than the ones currently available for containers.
But it’s also worth keeping in mind that the security challenges related to containers, and the value you get from a company like Red Hat if you choose that route for deploying containers, are not a new story. This is very much the same type of issue that you would face if you deployed a community-supported Linux distribution, like Debian, in your data center, rather than going with a commercial one that offers automatic security patches.
In other words, the security management challenges you face from deploying Docker (or any other container platform) on your own are not very different from running Debian (or any other non-commercial Linux platform) without an official support plan. In both cases, keeping your software patched and secure is on you.
Today, plenty of companies choose Red Hat Enterprise Linux or a similar commercial solution for their server rooms. Plenty of others go with the DIY, community-supported approach. Both solutions are perfectly viable, as long as you plan accordingly.
From this perspective, it seems like a weak argument to say that you need to use something like RHEL Atomic Host in order to guarantee container security. But at the same time, there’s no denying that an integrated container solution will make it much easier to avoid attacks that result from known security problems.
This is a long way of saying that, as the container ecosystem continues to develop, enterprises will probably fall into one of two camps. Some will decide that it makes sense for them to pay vendors to deal with security and other management issues for them. Others will set up their own infrastructure. Either strategy is fine as long as it is consistent with a particular company’s needs and resources.