alphaspirit - Fotolia
Customers respond to Docker Hub security breach
A Docker Hub data breach was top of mind at DockerCon this week, but users mostly waved off its broad impact as enterprises generally have their containers on lockdown.
SAN FRANCISCO -- Under the lights of its annual conference, Docker took time away from its latest enterprise container platform updates to discuss the recent data breach, and despite reassurances some customers are on guard.
On April 25, Docker discovered a data breach in Docker Hub, a repository of free Docker app images, that may have impacted about 190,000 accounts or just fewer than 5% of the service's users. That data included usernames and hashed passwords for the Docker users, as well as GitHub and Atlassian Bitbucket tokens for Docker autobuilds, according to Kent Lamb, director of support at Docker, in an email to users. All of those tokens were revoked, he said.
During his keynote here at DockerCon, Kal De, CTO of Docker, reinforced Docker's commitment to security and the company's security-by-design approach. "We will continue to do the best we possibly can," he said.
Later, in a press-only briefing, Docker CEO Steve Singh noted that bad actors constantly seek to attack systems, even those that are secure-by-design such as Docker's. A forensic investigation is underway into the Docker Hub security breach, and Docker has enlisted outside assistance to help with analysis.
"Bringing in outside assistance is a standard part of how we react to any type of breach, Singh said. "It's a standard professional model for response."
Docker continues to address security in its products, particularly for containers used in IoT and edge applications, and also takes advantage of hardware-based security, De said. The company works with partners such as Arm and Intel to create a platform-agnostic security layer, which utilizes the security modules available on the platform on which the runtime exists and auto-selects the most secure option, he said.
Users mull Docker Hub security
Despite Docker's assurances, three engineers from the heavily regulated healthcare and insurance industries said the breach gives them pause.
Chris Chapman Senior vice president of software development, MacStadium
"Overall, it gives us pause that there may still be vulnerabilities that can be exploited," said one of the three who requested anonymity. However, he also acknowledged that the company seems to have addressed the problem.
Organizations can mitigate incidents such as this Docker Hub security breach through tight control over their artifacts, said another healthcare provider engineer who requested anonymity. "Everyone pretty much uses JFrog for internal artifacts to keep track of their artifacts and not open themselves to attack," he said.
Moreover, in healthcare at least, regulators are often behind the curve on the newer tools, particularly in security, he said.
Noah, a software engineer for a large Midwestern telecom firm who also requested anonymity, said he is not too concerned about the breach, and Docker appeared to handle it the best way possible.
"Security tokens for automated build processes were vulnerable in that breach, but Docker invalidated those tokens, which is the best thing you can do," he said.
Josh Berkus, Kubernetes community manager at Red Hat, said he is not particularly worried about the Docker Hub security breach, first because Red Hat does not use Docker Hub and secondly because of its conventional nature. "It was just logins; nobody really got hurt," he said.
Security with containers is both a blessing and a curse, because the traditional security model doesn't apply, said Chris Chapman, senior vice president of software development at MacStadium, which provides CI/CD and DevOps services to Mac environments.
"In one sense you gain security because everything is in its own container," he said. "But then you have to watch all the containers to see who they talk to. You don't want any unsafe containers to be able to talk to you."
This is why with containers you do security scans early and often, Chapman said. You have to "shift left," or think of security earlier in the development cycle before moving to production. Then you "shift right," which is to watch for security all throughout the rest of the app lifecycle.