Kubernetes Vulnerability Scanning: What You Should Know

What is Kubernetes Vulnerability Scanning?

Kubernetes vulnerability scanning is an important way to identify and remediate security gaps in Kubernetes deployments. The process involves updating Kubernetes itself when vulnerabilities are discovered in the open source project, scanning container images and open source elements within them for vulnerabilities, and ensuring Kubernetes configuration meets best practices and compliance requirements.

Container vulnerability scanning is usually not performed manually. There is a wide range of tools you can leverage for this purpose—notable open source Kubernetes security scanners include Kube Hunter, Trivy, Kubei, Clair, and Anchore.

In this article, you will learn:

• Elements of Vulnerability Scanning for Kubernetes
• Recent Kubernetes Vulnerabilities
• Top Kubernetes Security Scanners

Elements of Vulnerability Scanning for Kubernetes

There are three key elements of Kubernetes vulnerability scanning: remediating vulnerabilities in Kubernetes itself, container image scanning, and testing for best practices in Kubernetes configurations.

Vulnerabilities in Kubernetes

The Kubernetes project itself, like any large open source project, has been subject to several security vulnerabilities. It is important to be aware of new vulnerabilities, and have a process in place to quickly upgrade Kubernetes when security updates are issued. See a list of recent Kubernetes vulnerabilities in the following section.

Related content: read our guide to vulnerability management ›

Container Image Scanning

An important security measure for any containerized environment is security scanning for container images. Image scanning should be enforced in all organizational processes, ensuring that untested images are never used in production Kubernetes clusters, or preferably in any Kubernetes environment.

The role of a container image scanner is to check all software on the image and report any vulnerabilities found. Images are usually based on one or more Linux distributions such as Ubuntu, Amazon Linux, and Alpine. The scanning program must support each distribution used by your organization, because every Linux distribution has its own security patch handling method. 

At a minimum, image scanners should be able to identify vulnerabilities listed in the National Vulnerability Database (NVD) and Linux distribution security advisories. Preferably, it should have additional sources for identifying new vulnerabilities in images or their components.

Typically, package managers are used to install software on the image at build time. The scanner must also support the package manager, so that it can detect version information and explore dependency trees. Language support is another important feature, because language-specific dependencies and libraries used by the application can also be vulnerable.

Related content: read our guide to container images ›

Scanning for Best Practices and Compliance Requirements

In addition to vulnerability scanning, a comprehensive vulnerability scanning process for Kubernetes should compare application architectures with best practices, to identify vulnerabilities and misconfigurations. 

A process should also incorporate compliance scanning—inspecting Kubernetes deployments for specific requirements of compliance standards that affect your organization, such as confidentiality of sensitive data, ingress/outgress data flows, secure configuration.

Learn more in our detailed guides about:

• Kubernetes security best practices ›
• Kubernetes CIS Benchmark ›

Recent Kubernetes Vulnerabilities

Here are some of the most recent vulnerabilities discovered in Kubernetes. 

CVE-2021-25735

A security issue has been found in kube-apiserver, which can cause updates of Kubernetes nodes to bypass validation of admission webhooks. This vulnerability only affects the authorization check network hook on partially denied nodes. It only applies to authentication plugins that use previous values of specific fields (not those invoked directly via the NodeRestriction plugin).

Versions affected: kube-apiserver v1.20.0-v1.20.5, v1.19.0-v1.19.9, <= v1.18.17

Kubernetes Node Vulnerability (CVE-2020-8558)

This vulnerability is a security issue discovered in kube-proxy, a network component that runs on Kubernetes nodes. It exposes internal services of Kubernetes nodes, allowing them to be accessed remotely without authentication. 

In some Kubernetes deployments, this exposes the API server insecure port, allowing an unauthenticated attacker to take full control of the cluster. This can lead to severe consequences including data theft, deployment or malware or cryptocurrency software, and corruption or loss of Kubernetes workloads.

This vulnerability exposes a node’s localhost service to hosts on the local network and to pods running on the node. Services bound to the localhost may often handle unauthenticated requests because they expect only local trusted processes will interact with them. If the node runs the localhost service without forcing authentication, it will be affected by this vulnerability.

Apart from patching this severe vulnerability, an important best practice that can limit its extent is to disable insecure port on the API server.

Versions affected: Kubernetes versions 1.1.0-1.16.10, 1.17.0-1.17.6, 1.18.0-1.18.3

Man in the Middle Vulnerability in Kubernetes (CVE-2020-8554)

This vulnerability is exploited by attackers launching a man-in-the-middle (MITM) attack, which let attackers eavesdrop on communications. The vulnerability exists in all versions of Kubernetes, and poses a significant threat on multitenant clusters.

A major risk factor of the MITM vulnerability is that it enables users with basic permissions to cause damage. Even users who can create or edit services and pods can exploit this vulnerability and intercept traffic from other pods located in the same cluster. 

When users create a service, they can specify a cluster IP address and expose services using external IP addresses. Then, the traffic from the cluster that is intended to the external IP address  can be routed to the service. Once it reaches the service, the user can intercept it.

Kubernetes API Server Vulnerability (CVE-2019-11247)

The Kubernetes API server vulnerability was discovered in 2019. Immediately after discovery, a patch was released to address the issue. However, the patch fixes the issue in versions 1.13, 1.14, and 1.15. Previous versions of Kubernetes were not patched.

This vulnerability exploits the Kubernetes API. It enables users to read, change, and delete custom resources in the cluster. In this case, role-based access control (RBAC) permissions, which extend to namespace resources only, can not help.

The Kubernetes API vulnerability can cause significant damage to anyone using  Custom Resource Definitions (CRDs) for Kubernetes clusters. To prevent attackers from exploiting the vulnerability, use the patched versions of Kubernetes—1.13 or further. 

Versions affected: Kubernetes versions up to 1.15 (patched in 1.13, 1.14, 1.15)

Kubernetes API DoS Vulnerability (CVE-2019-1002100)

This vulnerability enables attackers to exploit the Kubernetes API server for a denial of service (DoS) attack. The vulnerability lets users with write permissions make requests and tell the API server to use an excessive amount of resources. 

The scope of this vulnerability is significant—and many versions of Kubernetes, including 1.0-1.13, were impacted. The vulnerability was patched—Kubernetes RBAC was reconfigured and it now allows only trusted users to make patch requests.

Versions affected: Kubernetes versions up to 1.13 (patched)

Top Kubernetes Security Scanners

Here are several free and open source tools that can help you identify vulnerabilities in Kubernetes environments

Kube Hunter

Kube Hunter is a penetration testing tool for Kubernetes clusters, created and open sourced by Aqua Security. It offers a variety of scanning options such as remote, interlaced, and network scans to identify vulnerabilities. Its library of active and passive tests can identify most vulnerabilities in your Kubernetes clusters:

• Passive tests scan the cluster and identify vulnerabilities for remediation. Examples of passive tests include API Service Discovery, Kubernetes Dashboard Discovery, and Etcd Service testing.
• Active tests, disabled by default, may perform state-changing operations on a cluster, which can discover additional vulnerabilities, but requires close monitoring

Trivy

Trivy, another open source tool by Aqua Security, is a comprehensive and easy-to-use open source vulnerability scanner for container images. Since its launch, the project has gained a large following, with over 3,300 GitHub stars. 

Unlike other open source scanners, Trivy deals with both operating system vulnerabilities and language-specific dependencies, making it easy to integrate into your organization’s software development pipeline.

Trivy is available under the Apache 2 license and is free to use, modify and distribute. It is included as a native scanner for Harbor, the Cloud Native Computing Foundation’s popular open source container image registry project. It is also offered as an integrated scanner by the Mirantis Docker Enterprise platform.

Kubei

Kubei is a tool used to scan container images in Kubernetes clusters. Most of Kubei is written in the Go programming language. It covers all CIS Docker benchmark tests.

Kubeaito scans all images used in a Kubernetes cluster, including worker pods and control plane pods. You can customize your scans based on target vulnerability level, scan speed, and scan range, and more. View all the vulnerabilities found across the Kubernetes cluster on one dashboard, with remediation recommendations.

Clair

Clair is an open source project that provides tools to monitor container security by statically analyzing vulnerabilities in both Docker and appc containers. Clair is an API-based analysis that integrates with build and automation tools, letting you continuously monitor container vulnerabilities as part of the development lifecycle. It also supports three package managers: Debian dpkg, Ubuntu dpkg, and yum.

Clair’s container scanning engine checks whether there are any known security vulnerabilities in each container layer. Layers can be shared between multiple containers, so internal inspection is essential to inventory software packages and match known CVEs.

Clair scans all container layers and provides notifications of potential threats and vulnerabilities based on the CVE databases, and vulnerability research from Red Hat, Ubuntu and Debian. 

Anchore

Anchore Engine is an open source project that provides centralized services for container image inspection, analysis, and authentication. It is available as a Docker container image and can run independently or as part of any container orchestrator or managed Kubernetes service. 

Anchore Engine can download and analyzes container images from Docker V2 compatible registries, and evaluate them based on security and compliance best practices, and customizable policies.

Anchore Engine can be accessed directly through a RESTful API or the Anchore CLI. The commercial version of Anchore provides a graphical UI with features like policy management, user management, summary dashboards and reports.