Today, Cisco Cloud Native Security is happy to announce Kubei, an open source Kubernetes runtime vulnerabilities scanner tool, as a contribution to the developer and DevOps community. The tool is available on GitHub.
The idea behind Kubei is to offer the community a unique tool to help DevOps/SRE teams solve the pressing need for Kubernetes runtime scanning. While there are many tools available for vulnerability scanning, not all tools are created equal.
These tools differ by the number of feeds they consume, the updates they produce, and the depth of information they provide (which contains too many details). Vulnerabilities scanning is now part of all basic tiers in the cloud vendor images registries (e.g. Google Containers registry, Azure Container registry services), and there are many options available to choose from.
Despite the proliferation of open source and paid tools to scan container images, the scanning paradigm is similar in all of them. All scanning tools require some form of preliminary integration in order to provide visibility to the risk associated with the deployed containers. The scanning process takes place either in the CI/CD pipelines (which integrate the vulnerabilities scanners in the continuous integration (CI) workflow), or in the images registries, prior to the containers deployment phase. Some tools provide daily results of newly discovered vulnerabilities and even block the deployments of vulnerable containers. All tools, however, require some preliminary integrations to assess accurately the vulnerabilities risk associated with containers deployed in their Kubernetes clusters.
The challenges of this common and well established security best practice is the need for preliminary scanning integrations, without which, DevOps, DevSecOps, and Security teams have no visibility into the actual risk that containers deployed in their Kubernetes clusters have, or impose on their microservices, despite the fact that the actual risk frontier is in these Kubernetes clusters.
The lack of an accurate risk assessment snapshot isn’t the only challenge of the current security paradigm. Even when these preliminary integrations are performed,at the relevant integration points, users will still need additional tools to identify which pods were built from vulnerable images. Even with knowledge about vulnerable images, users still lack visibility into which of those images is being used by which container/pod and where it is deployed (if at all).
That is why Cisco Cloud Native Security has invested in a new runtime oriented vulnerabilities scanner.
Kubei is a new vulnerabilities scanner that offers a new security paradigm and operations model.
Kubei provides DevSecOps teams accurate risk assessment of deployed containers without the need for preliminary integrations in CI pipelines or image registries.
Kubei provides real time risk assessment of deployed pods, including application pods and Kubernetes pods, providing full coverage even for elements which are not always scanned (for example public images, not stored on your registry, that were not created in the user CI workflow, or even the Kubernetes API server and Istio/Servicemesh control-plane).
When you run Kubei on a Kubernetes cluster, it will extract a list of the images that were used to create running pods. Kubei will pull these images from the registry that was used by Kubernetes to create the pods, and will then start scanning these pods. In order to provide a quick response, Kubei will run parallel scanners to distribute the scanning load. Kubei will generate a report that shows users the exact location of the pods that create the risk, the images they built from, and the specific components in the image which contain the vulnerabilities, thus allowing the DevSecOps team a quick and accurate risk mitigation process.
You can configure Kubei to set the number of parallel scans, the risk level for detected vulnerabilities, and the specific namespaces that you are interested in scanning or ignoring.
As a prerequisite, you need to have a Kubernetes cluster with kubeconfig ( ~/.kube/config) properly configured for the target cluster. Use the The file deploy/kubei.yaml (available at Kubei) to deploy Kubei in the cluster. You can edit and configure this file to customize the Kubei deployment settings. Set the scope of the scanning, to define which namespaces should be ignored, using the parameter ignore namespaces (for example, The kube-system namespace). You can also set and control the scan process duration by running parallel scanners simultaneously. Set max-parallelism to the number of parallel scanners which can be used when Kubei runs. To use Kubei, run the following command: kubectl apply -f https://raw.githubusercontent.com/Portshift/kubei/master/deploy/kubei.yaml Then, run this command to configure the port for communication: Run the following command to verify that Kubei is up and running: kubectl -n kubei get pod -lapp=kubei