I am stating the obvious when I note that the container ecosystem has blossomed dramatically over the past year. Sure, the idea of using a container architecture to glean more efficiency from cloud deployments has been around for some time, but the past 12 months have seen that concept take wings.
But the reality is that the use of containers in a production environment can be quite complex. There are dozens of different aspects that need to be addressed in order to support a level of application quality needed by many organizations.
Perhaps the most important of which is security. Gartner recently had security and governance at the top of a list of best practices needed for creating a container platform strategy.
"Security is a particularly challenging issue for production container deployments," the firm wrote. "The integrity of the shared host OS kernel is critical to the integrity and isolation of the containers that run on top of it. A hardened, patched, minimalist OS should be used as the host OS, and containers should be monitored on an ongoing basis for vulnerabilities and malware to ensure a trusted service delivery."
Basically, container security is important. And, I am reminded of this on a near daily basis from companies that just so happen to have a container security product or platform. (Imagine that!)
I dare you to search through the SDxCentral archives for "container security." Or better yet, I will just let you know there have been a lot of stories on the topic, though not as many as there could be. (We are only human.)
Each of these platforms claims some sort of uniqueness in the market by virtue of some secret sauce or deployment model, which is amazing when you consider the small and tightly integrated environment containers are designed to operate in.
However, after discussions with a lot of container security firms, I would like to proffer that the current container security market is overwhelmed with ideas. Most of these ideas seem legit and appear to tackle various attack surfaces within the container ecosystem.
But, I can imagine the last thing the head of an organization's IT department wants to do is implement a new security protocol, let alone several different security protocols to handle those attack surfaces.
Should the IT department focus on threats to the build environment; container workloads and content; runtime; the operating system; or orchestration management? I thought containers were supposed to make things easier?
The variety of solutions is crazy, as are the amount of claims and counter-claims that come along for the ride.
Those offering a broader security package note they are seeing the most traction because organizations want a one-stop shop. Those pitching more specific platforms claim only they can truly secure whatever area of focus they represent, and that organizations want that sort of focus dedicated to container deployments.
Many of these briefings lead me back to a comment made by Facebook Chief Security Officer Alex Stamos at last year's Black Hat USA event. Stamos claimed that too much effort was being put into targeting security flaws that would likely only occur in extreme situations.
Or a conversation I had with Mark Balch, vice president of product and marketing at Diamanti, who said: "Containers today don't have the same level of isolation as a virtual machine. But there is a large continuum between 'I don't care about security,' and 'I need 100 percent security guaranteed.' As people become more educated on what those differences are, they will become more comfortable in running in fully containerized environments instead of VMs."
Adrian Lane, analyst and CTO at Securosis, perhaps put it best when he simply said the current container security environment is like the "wild, wild, west."
I guess at this point in the game, having more attention on container security is better than too little attention. Better to be too cautious than not cautious enough.
However, the confusion that comes with dozens of different players touting different platforms has to be challenging for those tasked with actually having to secure an organization's infrastructure. I know we are all not going to fit inside of a DeLorean and zoom back in time when enterprise security was handled with a lock and key. (Though Lane's comment does provide a nice "Back to the Future Part III" visual of taking a DeLorean trip back to the "wild, wild, west.")
Any amount of confusion to an enterprise IT department is likely to result in a delay in decision making or a security lapse. That was made obvious by recent news that hackers managed to infiltrate Tesla's Kubernetes console because it lacked basic password protection. The security firm that found the breach laid out a number of steps that if taken could have blocked the attack, but why should there have been so many steps to begin with?
I know containers and security are complex. But why do the solutions have to be?
Comments