Operational Security is Critical for Container Safety

The container ecosystem is, as expected, growing. Security solutions are popping up that promise to provide better protection of containers and communications between them. That's a good thing, because a Tripwire report on the State of Container Security found that 94% of respondents were "somewhat or very concerned" about container security. We need solutions that scan, verify, lock down, and securely manage secrets to help protect this emerging infrastructure and the applications they deliver.

That's the good news. Now for the bad news.

Despite these concerns, less than half (47%) in the Tripwire survey cite security as impeding greater container adoption rates. That means more than half are plowing ahead despite knowing the risks.  To wit, the same survey found that 17% of respondents have vulnerable containers, know what those vulnerabilities are, but have deployed them anyway.

Humph.

The publication of CVE-2019-5736 - which is still undergoing analysis - should be a wake-up call for those who tend to be less, oh, aggressive about ensuring security before deployment. If you hadn't heard about the vulnerability in runc, let me recap. runc is one of the more commonly deployed container runtimes. It's basically a tool used to spawn and run containers based on the Open Container Initiative (OCI) specification. So it's pretty important to operating containerized environments. It's also (allegedly) vulnerable to being overwritten by attackers if said attackers were able to control a container image launched within the environment.

Which is likely easier than you think, given that containers introduce significant operational security challenges as well as the ones associated with the containers themselves.

For example, reading through various reports on container security based on running environments you will find a goodly number (read: more than zero) of container environments running in the public cloud have absolutely no access control on their consoles. Which means you or me or an attacker can gain access simply by finding it. Access to the console means a compromised container can be launched, which enables the exploitation of CVE-2019-5736. Voila. I have root-level access to your environment.

Oh, but you're not one of those organizations, right? You have properly secured your consoles and require complex passwords. But do you allow loading of images from external sources? A 2018 KubeCon survey found that 73% have already adopted container registries - from which updated images are acquired.  According to a Sysdig report on actual Docker usage, 30% of respondents update container images on a daily basis. 8% of those update every 5-10 minutes.

Hopefully, these are coming from private container registries. Because a poisoned image can offer the same access. And it happens. It happened when we relied on RPMs to expand and update our Linux-based systems, and it happens to developers who rely on third-party components for application functionality.

Expanded focus is needed

The problem with container security initiatives right now is that we're focusing primarily on the containers themselves. We're so focused on container-to-container communications, deploying mutual TLS between containers, and arguing over how best to protect containerized systems from attack that we're forgetting about the significance of operations on security.

You wouldn't deploy a J2EE application with open access to its administrative console, would you? But some are apparently willing to do so when it comes to containers, even though allowing unfettered access to any environmental controls is simply bad security.

The same is true for blindly trusting third-party sources for images in real time. Images you are relying on should be vetted and certified and served up from a private, controlled repository. Allowing external images enables attackers to effectively push compromised containers by tricking you into loading them. And even if they're coming from a private repository, scan them. Every. Single. Time.

There are good reasons to be concerned about internal security with containers and how we should resolve them. But there are just as many good reasons to be concerned about operational security with containers and how to resolve it, too. The reason we focus on the former and try to brush the latter under the rug is that internal security can be - and likely will be - resolved with technology. Operational security too often falls under "behavior and practices" and that, as we know from the bumpy road to DevOps adoption, is a bigger challenge than both.