If you haven’t yet heard, a major security vulnerability was discovered in Kubernetes this week that opens the door for hackers to commandeer entire compute nodes through the Kubernetes application programming interface (API) server.

Many groups have already released technical details of the vulnerability, dubbed CVE-2018-1002105. They mostly are jumping on the bandwagon of how critical this is, but we haven’t seen much yet on the true exposure and risk of most Kubernetes clusters. It really depends on the exposure of the affected service.

If the API interface can be accessed, it is possible to take control of containers and other parts of the cluster. However, it is very difficult to determine if someone has “exploited” a cluster due to lack of logging details. This is what makes this a critical issue.

Let’s review what we know and steps you can take from a security standpoint.

Kubernetes Vulnerability: What We Know

The vulnerability could allow hackers to steal data, corrupt systems, or inject malicious code. According to Kubernetes developers:

“With a specially crafted request, users that are authorized to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection.”

What’s worse, “because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log.”

You can read a more detailed technical explanation of what caused the Kubernetes security hole over at the Gravitational Blog, which also has a proof of concept.

How to Secure Kubernetes

This is potentially a very critical issue that needs to be addressed. With proofs of concept exploits in the wild, someone will quickly weaponize it and attempt to attack exposed Kubernetes systems.

So, from a security standpoint, be sure to take the following steps:

Survey Your Technology Inventory

Identify Kubernetes clusters, how they are accessed, and their level of exposure to the API interface in preparation to remediate.

The criticality of the issue is really determined by the exposure of your Kubernetes cluster. If access to the API interface is limited, then the urgency is reduced but not removed.

Patch

If your Kubernetes cluster is exposed to the Internet, then you need to patch/upgrade as soon as possible. You should then re-evaluate and limit how the cluster is exposed.

Harden Your Kubernetes Clusters

Always limit exposure to administrative/management interfaces. The Center for Internet Security has released a security benchmark for Kubernetes. This should be evaluated as part of your hardening and security process.

Stay Updated

Like any other tool or service you use, always monitor for updates, patches, and security guidance. There have been several recommended mitigations, such as removing anonymous access, which may reduce the attack surface. It is unclear on how difficult this is and if it would be easier to just upgrade the cluster.

Develop a Container Security Strategy

If your organization is using container technologies, then you need to have a container security strategy. This is a new and ever-changing technology that is being deployed faster than many security teams can understand and secure.

With the rising popularity of containers and Kubernetes across the industry, including the top public cloud providers, there will likely be more critical vulnerabilities discovered in Kubernetes and container technologies.

Now is a great time to review your security posture and develop a comprehensive container security strategy.