Why You Need a Kubernetes Bill of Materials (KBOM)

You’ve probably heard of software bills of materials (SBOMs). And you may already be familiar with infrastructure bills of materials (IBOM) as well. Both ideas are garnering much attention lately as a response to increasing software supply chain risks and government mandates. And now, some IT pundits say the industry needs to drop one more bomb—a KBOM.

Kubernetes Security Operations Center, or KSOC, a cloud-native security company, just announced the first Kubernetes Bill of Materials (KBOM) standard. A KBOM can be easily generated and produce a list of the components installed in a given Kubernetes cluster. Encouraging the generation and sharing of KBOMs could bring increased visibility into cloud-native components, especially for large IT offerings that integrate Kubernetes into their offerings.

I recently spoke with Jimmy Mesta, co-founder and CTO, KSOC Labs, to learn more about the KBOM standard and why it’s come about. According to Mesta, Kubernetes is being treated as the new default. It’s like its own operating system, with many components that need to be meticulously tracked. Below, we’ll consider why IT needs more awareness of the inner workings of Kubernetes and consider the advantages of producing a Kubernetes-specific bill of materials. We’ll briefly examine how the KBOM standard is structured and how to build one yourself.

Understanding the Need for KBOMs

Similar to the requirement that food products list ingredients on their labels, software providers are under mounting pressure to share the technical details that make up their offerings so that consumers are aware of potential vulnerabilities in the dependencies.

Simultaneously, Kubernetes usage has exploded (96% of organizations use Kubernetes to orchestrate container deployments, according to the CNCF) and multicluster has become more common. According to Mesta, KBOM arose out of the desire to standardize and simplify large-scale Kubernetes deployments. “You can use KBOM to give up to a millisecond representation of the cluster and the associated assets,” he described. With a better window into Kubernetes ecosystems, the hope is that users can make more informed supply chain decisions.

Digging Into KBOM

It’s quite easy to create a KBOM. First, install KBOM with the following command: brew install ksoclabs/homebrew-kbom/kbom. Next, use the command KBOM generate to generate a KBOM for your Kubernetes cluster.

The output provides an initial specification in JSON, which is intended to fit with other SBOM standards and to be extensible across cloud service providers. Here is the high-level object model for a KBOM:

Cluster Details

Instances

Name
Hostname
CloudType
Creation Timestamp
Capacity
OS Version
Kernel Version
Architecture
CRI Version
Kubelet Version
Kube Proxy Version
Images

Name
Digest
KubeObjects

Kind
Api Version
Count
Details

The KBOM standard can generate some helpful metadata and will list things like the images running in a cluster, the digest associated with them, API versions of Kubernetes objects, kernel versions and asset inventory, among other data points. KBOM works with most versions of Kubernetes and is backward compatible to v1.19.

The full KBOM output for a Kubernetes cluster is about ten thousand lines of JSON. This includes the full report, with scans of resources, nodes and the images on each node. A shorter version might amount to about 600 lines of JSON, including simpler metadata, node info and resource information. For a large cluster, the file size might be around 5MB, estimated Mesta. Comprehensive enough to be helpful but small enough to work with in the terminal.

As Mesta noted, KBOM is an open source project, still accepting feedback from the community to expand the overall structure. For example, the project is considering how to add more cloud context—such as EKS-specific descriptions, IAM roles and load balancers—into the specification.

Benefits of Adopting KBOM

The most obvious benefit of using KBOM is to expose common vulnerabilities and exposures (CVEs) within your K8s clusters. Currently, there’s no ideal mechanism to ask multiple clusters at once if they’re running a vulnerable version. With KBOM, you’re only a query away from seeing the affected clusters. The ability to quickly assess the security posture of any cluster at any given time is quite valuable.

In a way, Kubernetes has become a standard software distribution format for SaaS products in the cloud. With KBOM, software providers could ship the specification with their software. Such an artifact would help end users assess risks before bringing a tool into their environments. Also, since the KBOM standard discovers the cost and type of hosting service, it could also be used to decrease bloat and inform cost savings mechanisms, said Mesta.

Of course, time will tell if software providers localize around using the KBOM standard within their deployments. To influence KBOM usage, Mesta notes that the project must hook into what people are already expecting in the SBOM world. Tying it to a unified bill of materials is the next logical step so consumers aren’t juggling various SBOM flavors. But right now, the important part is collecting the data, determining how you get it and what APIs you need to talk to, he said.

KBOM: Now Open For Feedback

The team is also considering how KBOM can be extended into other cloud-native cybersecurity toolsets. For example, hooking the generated KBOM into an automated CVE detection solution would be an obvious extension. Such a process would help engineers not only discover ingredients but correlate them to risks and ways to mitigate them. “It’s the wiring of other systems that make the project interesting.”

Naturally, influencing a standard to emerge will require some cross-industry collaboration. “These kinds of things get born out of being useful for the company that creates them,” said Mesta. But he reiterated that the goal is to make it a community effort. “We’re looking for feedback.”

Bill Doerrfeld

Bill Doerrfeld is a tech journalist and analyst. His beat is cloud technologies, specifically the web API economy. He began researching APIs as an Associate Editor at ProgrammableWeb, and since 2015 has been the Editor at Nordic APIs, a high-impact blog on API strategy for providers. He loves discovering new trends, interviewing key contributors, and researching new technology. He also gets out into the world to speak occasionally.

Bill Doerrfeld has 105 posts and counting. See all posts by Bill Doerrfeld