Container Security, Unverified Images and Docker Vulnerabilities
Container Security, Unverified Images, and Docker Vulnerabilities
Containers have only recently started to go mainstream as an important part of continuous integration and delivery (CI/CD). This is great for developer autonomy and individual ownership, but what about security? While Docker and Kubernetes have been the main drivers of this rapid container adoption, the ease at which these two orchestrators allow anyone to deploy code can leave security in peril. Does the fact that these are open-source platforms make it even more or less secure?
Most importantly, how much do users understand about container security?
This is some of what The New Stack founder Alex Williams was asking when he sat down at DockerCon with Tianon Gravi, senior vice president of operations at InfoSiftr, and Noah Abrahams, Kubernetes engineer at Ticketmaster.
At the end of May, the Docker Symlink-Race vulnerability was discovered in all versions of Docker container engines that offer an attacker a way to get to the host itself or any other containers managed by that host to not only read but modify the files.
Abrahams sees security as something that falls on a spectrum of passive versus active versus retrospective.
“To take something like Docker Hub and say, ‘Oh, well that’s based on provenance.” It’s based on how the images are stored.’ That’s going to be more passive. I’m not going to think about that in terms of an active security. I’m going to think about that in terms of something that’s already been done and I’m not going to mentally treat that with all of the respect that it deserves,” he said.
In security, we always need to think actively. And we always need to be learning.
Gravi pointed out that not many are talking about how May’s Docker attack involved Github tokens. This means the Symlink-Race vulnerability could compromise your source code.
He said this means an attack could “modify the settings of the Github repository to add a new deploy token that no one’s going to notice for months if they’re not actively auditing their access. “
Perhaps because this vulnerability doesn’t have a memorable name and icon (like “Heartbleed”), people aren’t understanding the gravitas of this attack, Gravi said. He said you must double-check that you’ve actively rotated your tokens and updated your passwords.
The conversation continues to talk about the growing sophistication of cloud service providers that should soon notice irregular behavior, like updating a different type of token that hasn’t been used before, and flag that code change.
On the other hand, Abrahams pointed out that labels are mutable — “because it’s inherent to the concept of labeling within the Docker environment” — which makes using a cryptographic hash — which if it doesn’t match the image, Docker will reject it — the most reliable current way to flag attacks.
Gravi took it to the next level and said that, if he is particularly reliant on a specific Docker image, he will try to take over maintenance of it so he’s the one responsible for the lifecycle of the image. Of course, he admitted, this isn’t scalable for larger organizations.
Both Gravi and Abrahams agree that more eyes are better than few, which has them arguing that open source is the future of containers. Abrahams then went on to predict those intrusion protection companies that traditionally focus on attack forensics will evolve toward proactively understanding what’s happening in containers in real-time. He continued that each of these companies will zoom in on a specific area and then hopefully collaborate and integrate with broader coverage.
Gravi echoed this by saying, “I think it’s in the customer’s best interest to call up their security vendors and say, ‘Hey, what are you guys doing on open source? How are you pushing the community forward? How are you making all of us better?’”
In this Edition:
1:58: How much customers understand about container security.
4:51: How to be more preventative.
10:41: Sorting through the issues.
14:05: Open source security.
19:43: Requirements for the major platform providers?
25:41: Exploring where the onus lies if something happens.
