Docker’s Inherent Lack of Security, the Black Hat View
At the Black Hat conference last week, I sat down with Adallom’s vice president of marketing, Tal Klein; EMC’s senior director of trust, Davi Ottenheimer; and Ryan Potter, Fortinet’s senior director of strategic alliances, to discuss the security features of Docker. We used this discussion as the starting point for a larger conversation about the rise of application development, the context of trust, and the industry’s overall flawed fascination with making things easy to use.
#9: Docker’s Inherent Lack of Security, the Black Hat View
Security becomes a secondary factor with the need to scale ever higher. The easier it is to run, the more likely you are to overlook the checks and balances.
There is no inherent security to a Docker container. The problem: when it’s too easy, issues arise.
We are moving into a world of proxies. Docker does not contain something as much as it provides a service. Compromises are inherent to Docker containers.
Docker reflects the desire for less and less friction. But security is designed to be just the opposite. Too often, though, the attention centers on the unknown, when in reality, attacks are far more often about social engineering. It’s human nature to give control to a few parties, exposing an organization to all sorts of vulnerabilities. The hacker will go after the admin. At cloud scale, this becomes more complicated. It is usually the cloud admin who has the keys to the kingdom. In fact, the admin often controls so much that it is his or her user credentials that are the keys to the kingdom.
Cloud security is still so new that customers tend to think about it using a traditional mind-set. Security vendors, in turn, try to craft a marketing response to customers by using traditional terms to sell them products.
Operations security is becoming a model for IT to follow. The people-building stuff has to have good security posture.
You should not trust Docker, trust Davi, which builds a trusted security framework.
The container model is misused. It makes sense in some respects; after all, you are containing something. But that doesn’t mean it’s secure. Still, containers are often discussed in the context of a trusted model.
We are not looking deeply enough into containment. Do I trust it not to break out? Do I trust it not to allow escape?
The container analogy breaks down in other ways as well. For example, consider the security of the container versus the security of the ship. The ship is the dock. You may be able to build a secure container, but if your ship is insecure, it doesn’t matter.
In the end, it really has to come down to a discipline that is missing in a scale-centric, quick-to-deploy market.
Docker does have a reduced target surface, but the threat is still there. The ones pushing it are the most knowledgeable, so the security issues are not as relevant as they will become when Docker gains wider acceptance. For now, Docker security is still a minor issue.
There are no Docker zero days.
Failure is an assumption for anyone building or managing cloud services, but the consequences are often not considered.
You want people to breathe and grow, but not to ignore their responsibilities.
A new DevOps culture increases the attack surface. The smart people are the ones who participate in the DevOps culture with humility.
If it has been invented before, there’s no need to invent it again.
Data has a different context in the cloud age. Geographic borders do not exist in the cloud. We need controls on data, which is a challenge to the security industry.
Data needs a notion of provenance, of where it is from.
However, it is not just the data but the controls as well. Can you trust the infrastructure provider? What liability is Amazon putting on itself? Do we trust Amazon? What do we trust Amazon with?
Our conversation concluded with a discussion about why it is important for the Docker community to be open to criticism. OpenStack is just beginning to be more accepting of critiques. People want to reinforce Docker’s success, but in the process they might ignore its frailties. Docker may reduce friction, but it also has none of the basic security capabilities. It’s analogous to driving a car without a seatbelt.
The headlines scream at us that planes are not safe, cars can be hacked, and there are more dangers and threats to us than we can possibly imagine. And there’s the rub—what we can possibly imagine dictates how we set security policies.
Just as challenging is the exuberance the tech press has for new technologies and the often resulting lack of any careful critique of what threats these new technologies may pose. Docker is the current symbol of this adoration. For months, there has been more excitement for the lightweight container than for any other open-source technology. It fits the times, really. It is designed for rapid application development at “cloud” scale, but little attention has been paid to its security capabilities.
We at The New Stack are bent by the sways of the developer community and its current fascination with Docker. We, too, seeing the VMware machine roll, have come away refreshed by the Docker movement, which makes virtualization technology heavy in comparison to these featherweight containers.
In this world, there are many adorers but few critics. And that’s a real problem. It’s like putting too much faith in anything without scrutinizing it fairly. The praise becomes entirely believable without room for critique and by extension, the necessary means to make it better before it matures too much. By that time, as history tells us, the fix becomes a bolt-on, tarnishing the once elegant jewel so many adored.