Cloud security provider Lacework found more than 21,000 open container orchestration and API management systems on the internet that were vulnerable as attack points for possible hacking. Those open systems included deployments using Kubernetes, Docker Inc.’s Swarm, Mesos Marathon, Red Hat OpenShift, Portain.io, and Swarmpit.

Dan Hubbard, chief security architect at Lacework, said the firm discovered the issues as part of research conducted earlier this month. That research found those deployments had publicly accessible management nodes connected to the internet that basically were open doors to an organization’s cloud environments.

"This demonstrates the lack of security maturity when it comes to deploying in public cloud," Hubbard said via email.

A vast majority (95 percent) of the nodes were hosted inside Amazon Web Services (AWS) with 55 percent hosted in an AWS U.S. Region. Some of the other clouds hosting the vulnerable nodes included Alibaba, Microsoft Azure, and Digital Ocean.

It was noted that most of the open nodes did have credentials set up, which would at least limit the ease in which someone could access the cloud deployments. But more than 300 of the open admin dashboards did not have any credentials required for access.

Hubbard noted in a blog post that such security issues were likely due to poorly configured resources, a lack of credentials, and the use of non-secure protocols.

“These nodes are essentially openings to these organization’s cloud environments to anyone with basic skills at searching the web,” the firm noted in its report. “Although the vast majority of these management interfaces have credentials set up, there is little reason why they should be world-accessible and are far more vulnerable than they should be. Additionally, just by being open, you are potentially disclosing information that can give attackers sensitive information on their targets.”

Specific to Kubernetes, Lacework found open dashboards that were in the midst of being set up and thus not fully protected; open dashboards with no authentication; open dashboards that could be “brute force” attacked using a certain level of skill; and information disclosures of the organizations that had deployed Kubernetes, thus giving an attacker a target to aim for.

"It depends on the motives and operation but to gain access is very rudimentary," Hubbard said in terms of the skill level required to execute an attack on the open systems. "You simply would have to know how to perform network scans or have a tool to do that and then know how to point and click in the interface."

The security firm recommended that organizations running Kubernetes should configure their pods to run read-only file systems; restrict privilege escalation to minimize the blast radius of an attack; and build a pod security policy.

More specifically, Hubbard said that while the security ecosystem was improving deployment models, it would be better if projects were shipped with "more restrictive defaults" and "security 'on.'"

"With respect to security, there are a lot of great things going on in this new world order, but we are also seeing generally a lack of visibility, audit, and understanding of the new infrastructure from security departments," he added.

The Kubernetes security issue was part of a cryptojacking attack earlier this year on Tesla. RedLock Cloud Security Intelligence found hackers had compromised Tesla’s Kubernetes console, which had not been password protected. One of those Kubernetes pods contained sensitive data, including telemetry information.

Kromtech Security earlier this month found a similar opening on a Kubernetes deployment by Weight Watchers.