Container images sometimes suffer from vulnerabilities ranging from negligible to critical. CVE-2019-11249, for example, is a Kubectl copy operation that, together with a malicious tar binary in the downloaded container, enables hackers to replace or create files on users’ machines even if the location is outside the destination directory of Kubectl copy operation. It can lead to a complete hostile takeover of the application pod, the Kubernetes node, and, in some cases, even the entire cluster.
Unfortunately, the list of vulnerabilities keeps growing, and their potential impact can lead to the swift annihilation of a corporate security and the reputation that took years or decades to build. But all hope is not lost.
The Current Scanning Paradigm
Currently, scanning images is typically performed either by hooking into the CI pipeline just before the image is pushed to the container’s directory and checking the scan result before adding the image to the registry or by scanning the entire registry to detect vulnerabilities. To tighten Kubernetes security, some commercial scanning solutions add a one-time validation to prevent the deployment of pods when a level of vulnerability exceeding a pre-defined score is detected.
Existing Scanning Tools
Leading current solutions include:
- "Aqua’s Trivy": A comprehensive container vulnerability scanner, easy to integrate with CI/CD
- "Anchore": Analyzes container images and applies user-defined policies to implement custom security checks. Checks for known CVEs and additional data such as DocuSign check and other credentials, language-specific packages, and more. Open Source
- "Snyk": Focuses on the development workflow. Connects directly to the core depository, parses the project manifesto, analyzes the imported code, the libraries dependencies, is compatible with multiple languages, and can uncover implicit licensing risks
- "Twistlock": Is an add-on to K8 clusters hosted on the cloud. It is compatible with most cloud service providers
- "Qualys": Based on embedded security, it scans original images with static analytic tools that check for CVEs and replace the original image with an image containing an injected binary designed to keep the environment secure.
- "Clair": Able to pull CVE information from a large number of vulnerability sources and focuses on vulnerability scanning and CVE matching Offers pluggable drivers
- "Jfrog": Created by KubeXRay that ensures that pods comply with existing policies and filters that can run on the Kubernetes cluster
All these tools have different feeds, UI, and CTAs, but function in a similar fashion and face the same challenges that compromise Kubernetes security
Existing Scanning Tools Challenges
- "Lack of preliminary integration": Without preliminary integrations in the CI/CD pipeline or the image registry, users are blind to their vulnerability risk
- "Agent per node": Adding agents on each node can be time and resource consuming, yet it needs to be done to check the data on pods containing borrowed images
- "External repositories & Sidecars": Pods imported from external sources might not have been scanned during CI/CF or repository scanning
- "Inefficient process": scanning image registry is inefficient as only a small portion of the images deployed at runtime are produced by developers, and typical off-the-shelf solution focus on scanning pods at deployment time
Why did we create Kubei?
Cisco Cloud Native Security steadily received increasing reports of issues stemming from the shortcomings mentioned above. Security teams were eager to understand security risks on Kubernetes clusters without running preliminary integration, and DevOps teams were hungry for efficient scanning solutions devoid of scalability bottlenecks and effective during Kubernetes deployments. Kubei is our answer to these issues.
What is Kubei?
Kubei is a runtime scanner designed to tighten security for temporary deployment in Kubernetes clusters with no preliminary integration. With Kubei, DevOps can:
- Scan all runtime images, CI/CD native or those imported from external sources to detect malicious pods and provide an extra layer of security to your cluster
- Scan public images in use even when not hosted on the local registry
- Get visibility into Kubernetes elements and possible vulnerabilities
- Generate accurate, real-time status reports of their clusters’ health
Kubei overview
A highly customized scanner, Kubei enables users to calibrate the span, depth and limits of the scan to privilege speed or security level. Kubei’s scanner can be customized to the user’s need by:
- "Span of the environment to scan": Users can select which clusters or namespaces to scan, and exclude specific namespaces
- "Vulnerability level": Users can define the minimum level of vulnerability to consider during the scan. All vulnerability levels below the selected level are ignored
- "Parallelism level": Users can set the number of scans to run in parallel, which drastically reduces the loss of speed due to heavy images that typically create a bottleneck and therefore increases the speed of vulnerability detection
After running a scan, the report generated by Kubei displays the results in a user-friendly table displaying the affected Pod Names and the related vulnerability and image name, the severity level of the vulnerability, and the exact package in which the vulnerability was identified.This enables users to easily identify and patch the specific package containing the vulnerability (See image below).
In addition to the calibrating options above, Kubei’s commercial version enables users to:
- Scan on Pod Creation
- Isolate vulnerable pods
- Run periodic scans
- Receive alerts on critical issues
- Selectively ignore vulnerabilities
Check out Kubei on Github here, released in March 2020, tried and tested by hundreds of DevOps
