The Kubernetes security community released a handful of new updates targeted at slaying a pair of bugs that could impact container operations. One of those bugs has been particularly difficult to eradicate as the latest fix is the third attempt at snuffing out the issue.

The two bugs are dubbed CVE-2019-11247 and CVE-2019-11249.

The former can allow access to a deeper set of container resources for someone with access to just a basic level of resources. More scientifically: “This vulnerability allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced,” wrote Joel Smith, who works with the Kubernetes Product Security Committee. “Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update, or delete the cluster-scoped resource (according to their namespace role privileges).”

Ubuntu, in a reference to fixes it implemented in its Canonical platform tied to the latest bugs, noted the bug was of “medium severity.”

The flaw impacts Kubernetes iterations between 1.7 and 1.15. It was initially reported by Prabu Shyam from Verizon Media.

The second bug is the persistent one. It can provide an infected or hacked container to be created or replaced on a developer’s computer when the developer uses the kubectl cp operation. This tool is what allows running commands against a Kubernetes cluster to deploy applications, inspect and manage cluster resources, and view logs. Smith noted that this “vulnerability is a client-side defect and requires user interaction to be exploited.”

The bug impacts various versions of Kubernetes dating back to the 1.10 release and all the way up through the 1.15 iteration.

This bug is a re-hash of incomplete fixes that were applied to its predecessors: CVE-2019-1002101 and CVE-2019-11246. The first one was initially found earlier this year by Ariel Zelivansky, a security researcher at Twistlock, and labeled as a “high” severity bug. That bug was also linked to patch that was sent out last year.

The second iteration was discovered in June by Charles Holmes from Atredis Partners, with Smith noting that the initial fix was not enough. “The original fix for that issue was incomplete and a new exploit method was discovered,” Smith wrote.

The latest version of this bug was found by Yang Yang from Amazon, who also provided the patch.

The Kubernetes Product Security Team targeted these latest issues with three updates. They are designed to update Kubernetes versions 1.13, 1.14, and 1.15.

And don’t expect these to be the last bugs found within Kubernetes. The community itself has repeatedly stated that such flaws are to be expected and that the main focus should be on how quickly it can send out updates.

Rani Osnat, vice president of product marketing at Aqua Security, previously told SDxCentral that Kubernetes is a “complex system and it’s bound to have vulnerabilities. The fact that CVE disclosures are becoming more commonplace is a good thing, as is the fact that they’re not all severe.”

Despite the assurances, container security remains a hot topic. A recent survey from StackRox found that while two-thirds of organizations are running more than 10% of their applications in a containerized environment, 40% of those organizations think their current security stance is not adequate to protect those environments.

Most of those concerns are over misconfigurations and accidental exposure of access to their containerized environments. However, a robust 43% stated concerns over runtime security, 35% specified concerns about deployment security, and 22% said they were worried about build security.

“Just as with securing [infrastructure-as-a-service], missing container and Kubernetes security best practices and human error in misconfigurations create real threats to organizations and their bottom lines,” said Mark Bouchard, co-founder and CEO of AimPoint Group, in a statement on the report. “The consequences of overlooking security early in the container life cycle will be steep, both in lost time and money and in risk of exploitation.”

Those concerns were behind Palo Alto Networks’ recent $410 million acquisition of container-focused security provider Twistlock.

“Today [customers] are talking about containers,” noted Nikesh Arora, chairman and CEO of Palo Alto Networks. “If you look at the market there are only two companies [securing containers] and Twistlock was by far the leader.” The other is thought to be Aqua Security.