Security is a funny, elusive thing. You will rarely hear a security professional describe something like “secure” - Liz Rice. Now when it comes to Kubernetes too, we have observed that its default settings had left the control plane insecure in important ways in the past. The situation gets further complicated by the fact that different installation tools may configure your deployment in different ways and leave it exposed to vulnerabilities.

Anyone who gains unauthorized access to your Kubernetes clusters can wreak mayhem with your existing services and even get access to your data. They might at the very least exploit your compute resources as we have seen earlier in the well-publicized case of “crypto-jacking” at Tesla. So as you continue your Kubernetes journey into 2021 and beyond, we at AccuKnox want you to know about five of the foremost high-risk security vulnerabilities reported so far in the previous year and shield yourself against them.

Man in the Middle vulnerability (CVE-2020-8554)

Discovered in December of 2020, this vulnerability was found to have the most significant impact on multi-tenant clusters and affected every version of Kubernetes that existed then. Any user with basic permissions such as creating or editing services and pods in a Kubernetes cluster was able to intercept traffic from other pods in the cluster through exploiting this MITM vulnerability. This meant that attacks can be carried out with less sophistication.

Remediation required Kubernetes administrators to restrict the use of external IPs through a Policy enforcement mechanism such as Kubearmor or OPA Gatekeeper.

Kube-proxy vulnerability (CVE-2020-8558)

On April 18, 2020, a security issue was made public that had been discovered in the Kube-proxy, a networking component running on Kubernetes nodes. The vulnerability exposed the localhost services which were meant to be accessible solely from the node itself, to all hosts on the local network, and to pods running on the node. On certain Kubernetes deployments, this was able to even expose the API-server, allowing any unauthorized attacker to gain complete control over the cluster. An attacker with this sort of access could deploy crypto miners, steal information or remove existing services altogether.

The Kubernetes security team had rated this vulnerability’s impact as High in clusters where the API-server insecure-port was enabled, and otherwise Medium. So there's a high chance that you were affected if your nodes run localhost services without enforcing authentication.

To protect yourself against this vulnerability ensure you’re using a patched version of Kubernetes (v1.16 or beyond).

Bypass of Kubernetes API Server proxy vulnerability(CVE-2020-8562)

A new security issue was discovered in April in Kubernetes, which could allow a remote authenticated attacker to obtain sensitive information. This was caused by a time-of-check time-of-use (TOCTOU) race condition flaw in the API Server proxy. By sending a custom-made request, an attacker could exploit this vulnerability to gain access to private networks on the Kubernetes control plane.

This vulnerability too carries an easy remediation solution - upgrade your Kubernetes Service clusters to version 1.18 or later.

Kubernetes Java client vulnerability (CVE-2020-8570)

A vulnerability classified as critical was found in Kubernetes Java Client up to 9.0.2/10.0.0. Affected by this vulnerability is a function of the component Pod Handler. Manipulating it with an unknown input leads to a directory traversal vulnerability. The CWE definition for vulnerability is CWE-22.

If you copy a file from a malicious pod with a specially crafted tarball, it may extract to any file that your user has permission to write. The exploitation appears to be quite easy. As an impact, it affects its confidentiality, integrity, and availability.

This issue was shortly fixed in releases 9.0.2, 10.0.1, and 11.0.0. So we strongly encourage you to upgrade to those versions.

CI/CD plugin vulnerability (CVE-2020-2121)

The attackers have turned their eyes towards Kubernetes CI/CD plugins now, which often prove to be a great target due to flaws like CloudShare and Arquillian vulnerabilities. The CVE-2020-2121 affects this plugin. The flaw stems from the YAML parser which allows instantiation of arbitrary types to allow remote code execution on the pod. It's easy to retrieve the plugin's password file which is stored by it on the pod itself, and the attacker successfully takes control over the Jenkins.

Since the role used by the plugin has ‘CREATE’ pod privileges on the cluster, as shown above, the attacker can therefore schedule pods on the cluster and create services or endpoints. If a proper PSP (PodSecurityPolicy) is not applied with something like AccuKnox, attackers can create pods with hostnetwork to attack the underlay network, and steal credentials as well stored on nodes using volume mounts.

You will need to have Jenkins Google Kubernetes Engine Plugin 0.8.1 version or up to fix this vulnerability.

Conclusion

Security vulnerabilities are a significant issue as more organizations come to rely on Kubernetes for their cloud containers. So, moving forward, it’s better you carry out the following to be on the safe side and beat these vulnerabilities:

• Be on the latest version of Kubernetes since all vulnerability mentioned here has been fixed.
• Scan your codebases for vulnerabilities.
• Ensure you are following security best practices.

AccuKnox security solutions offer isolation and protection functionality across Kubernetes infrastructures through networking and system-level restrictions over containers, to easily comply with a wide variety of compliance needs. To learn more about our Identity-driven security solution for Data, Kubernetes, and native VM workloads across Private and Public Clouds, reach out to AccuKnox today.

Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.

Let us know if you are seeking additional guidance in planning your cloud security program.