Introduction
The Kubernetes third-party ecosystem offers a plethora of plugins and tools that have become an extended part of Kubernetes environments. While Kubernetes is widely used to orchestrate container deployments, the recent spate of Common Vulnerabilities and Exposures (CVEs) in Kubernetes third-party tooling has suggested the need for a Kubernetes Bill of Materials (KBOM), which is designed to provide a quick view of the scope of a Kubernetes cluster. In this blog, we explore the new KBOM standard, as well as how it differs from the Infrastructure Bill of Materials (IBOM) and Software Bill of Materials (SBOM).
The Kubernetes third party ecosystem matters
To understand the sheer number of third party plugins and tools available for use as an extended part of your Kubernetes environment, look no further than the infamous, “CNCF Cloud Native Interactive Landscape.” There are tools for observability, low-code management, Kubernetes networking and more. But when it comes to the US Federal compliance regulations regarding the software supply chain, and despite the fact that Kubernetes is used by 96% of organizations today to orchestrate container deployments, Kubernetes has been largely passed over in favor of a focus on standalone containers.
In response to a recent spate of CVEs in Kubernetes third party tooling, and to help teams scope their cluster configurations so they can work more efficiently with external teams, KSOC has released a first open source standard for a Kubernetes Bill of Materials (KBOM).
SBOMs and IBOMs and KBOMs, oh my!
The obvious parallel for the KBOM is the Software Bill of Materials (SBOM), which has been included in the US Federal government’s compliance and accompanying NIST SP 800-218 guidelines for securing the software supply chain. The general purpose of an SBOM, as per the compliance regulations, is to be able to show the provenance of the components of your software to another party.
While there are standards for the SBOM like CycloneDX, SPDX, and one from GitHub, vendors include different information in their SBOMs, depending on various factors, such as which place in the lifecycle the SBOM was generated. If you’re creating an SBOM from a code repository, you’ll have different information than if you took the SBOM from CI/CD pipeline, or from a running Kubernetes environment, like we do at KSOC. Some vendors also include licensing information, while some don’t. The concept of an SBOM is not new (SPDX began in 2010), but its use as a part of securing the software supply chain and the new compliance guidelines have brought it into the spotlight.
A much less well known and utilized bill of materials is the Infrastructure Bill of Materials (IBOM). Two IBOMs were released in 2022; one open source and one proprietary solution. The initial intent for an IBOM was to lay out Infrastructure as Code (IaC) elements, a full list of inventory in the cloud (like RDS services or S3 buckets) and the security status of cloud providers. These suggested standards are not in wide use today, even while practices like GitOps, to better encapsulate deployment specifications in code, have exploded in popularity.
The IBOM options do include a nod toward Kubernetes capabilities in them. What is missing, that makes a KBOM helpful? And why doesn’t an SBOM fit the bill? In short, neither an SBOM or IBOM, as they are created today, are purpose-fit for Kubernetes in a way that will save teams time creating an accurate scope of their clusters. To adequately help teams with these outcomes, a laser focus on Kubernetes is required.
The Kubernetes Bill of Materials (KBOM) Specifications
The new KBOM standard is meant to provide a quick view of the scope of your Kubernetes cluster. In this first release, we have included:
- Cluster size (workload count)
- Cluster cost (node types, e.g. AWS/GCP/etc.)
- Vulnerabilities (both for internal and hosted images)
- Third party customizations and plugins (CRDs, authentication, service mesh, GitOps, management, and more)
- Version details for the managed platform, the kubelet, and more
Why a KBOM
We recently asked a group of participants at KubeCon whether, if they had container security, Cloud Security Posture Management (CSPM) and runtime security, they would still need dedicated security for Kubernetes. 97% said yes (and the other 3% said they didn’t know). Similarly, you can create a bill of materials for containers or for your cloud infrastructure, but neither of these will provide as much coverage as a bill of materials for Kubernetes itself.
For example, many SBOMs will only cover custom-built images. In terms of what is actually deployed in Kubernetes, looking only at bills of materials for custom images would completely miss third party images for the control plane or in the CRD, which would amount to a significant oversight in evaluating the components of a Kubernetes cluster. By including things such as CRDs and a public images list in the KBOM, many of the recent Kubernetes vulnerabilities can be identified quicker than using a standard SBOM or another method.
In the specifications of the IBOMs that have been released, the only parallel with the KBOM components appears to be workload count and potentially versioning for the managed platform. But there is a lot missing from the IBOMs that is specific to Kubernetes, such as vulnerabilities of images running in the cluster or the third party ecosystem.
This release is the first step to quickly figuring out whether you have a third party Kubernetes tool installed. In the case that one of these tools has disclosed a CVE, you will want to know this information quickly. You can also more easily work with third parties who need to know the answers to questions such as, ‘What is your cluster hosting model and kube-object information?’
An example scenario; using the new KBOM to quickly root out the latest
Kubernetes CVEs
The industry has recently seen vulnerabilities in third party plugins for Kubernetes, including Crossplane, the Jenkins plugin, CubeFS, and Clusternet. Each of these vulnerabilities would allow for privilege escalation in Kubernetes. The KBOM would bring visibility to each of these sooner, allowing for quicker fixes.
For example, in the case of the Clusternet vulnerability (CVE-2023-30622) or the CubeFS vulnerability (CVE-2023-30512), the KBOM would show the Clusternet or CubeFS images if you pulled a public image. In the case of Clusternet, this would also be highlighted when looking at the configured CRD's within the cluster. The Clusternet API leverages a CRD in your kube-apiserver. So the KBOM would've shown the Clusternet image if you pulled a public image and the CRD if you leveraged the Clusternet API.
Efficient teams need a view of their clusters’ configurations
The dearth of Kubernetes and security skills already has the potential to hold teams back, and historically teams have not had an efficient way to share cluster configurations efficiently with a third party, or across teams internally.
The KBOM provides a quick solution so teams can easily and quickly share their configuration parameters. It places the orchestrator at the forefront of the BOM structure by detailing cluster hosting model (DIY, managed with Cloud Service Provider), node counts and critical details (architecture, container runtime, kernel versions, OS, image), kube-object information, installed CRDs and a public image list. These pieces of information accurately described the overall posture of a cluster to better help discuss things such as costing, compliance, security posture and potentially more.
Conclusion
We openly invite collaboration and input for this standard, and believe the community should have a quick option for scoping clusters as well as identifying issues in third party Kubernetes tools. At KSOC, we also hope this tool will help bring Kubernetes front and center into the conversation when it comes to the software supply chain; it most definitely already front and center when it comes to deploying business-critical containerized applications.
To contribute, check out the Github repo here