Software Bill of Materials has grown in popularity and adoption from many open source software projects to provide transparency of software supply chain attestation of packages associated with the build of the software. While the aim of Software Bill of Materials aims to reduce or be the front protection in the movement behind software supply chain risk management. The organization CISA is also pushing this out to the public to increase software supply chain management I will include references to resources associated with SBOM later in this article.
Kubernetes Bill of Materials? Why?
First thought would be that marketing targeted a supervised group of interests to see how this acronym fit in the paradigm of security. Only this is really driven by the rapid adoption of kubernetes for many organizations that are regularly utilizing some form of hosted kubernetes clusters in public clouds, or self-hosted. To understand the components that we will gain visibility into reference the diagram below.
https://kubernetes.io/docs/concepts/overview/components/
This diagram above referenced above breaks down the components that are in scope of the visibility as you upgrade your clusters typically if your using cloud-hosted this can be abstracted to the end user these components are still independent components. While this paradigm of adoption has greatly accelerated the risk of the underlying operating system still remains the same and visibility should be increased on the orchestration platform.
Trivy
Aqua Security has a open-source tool trivy that is popular amongst cloud security it is featured in the CNCF CKS exam heavily for image scanning for CVE’s they’ve also added SBOM support along with KBOM features, for this demo I’m running on AKS v1.26.6 in East US. For some reason pulling the docker image and running the binary had issues reaching outbound to the vulnerability DB for scanning so for brevity I’m covering the outputs of a previous run in a kind cluster running.
To see this in action run the following commands in your terminal once you’ve authenticated into your cluster.
trivy k8s --report summary cluster
Your output is color coded with a few charts that run a workload assessment, rbac assessment along with the findings separated by category such as vulnerabilities and misconfiguration with the exact resources/namespace for quick identification.
Permissions especially in Kubernetes can cause chaos if not monitored and controlled this gives great visibility across the roles identified. Remember roles traditionally if not using a CSP’s RBAC native integration will have two categories (roles/clusterroles), a clusterrole has wide leverage because it is scoped to your entire cluster while a role can be granular to a namespace. The interactions in a cluster are dependent on the roles as you see some roles are scoped to system:controller associated with our default kube-system namespace below.
Additionally if you want a more turn-key approach in docker-desktop you can run the trivy extension and also generate SBOM’s I’ve ran a scan on the latest Kubernetes 1.28 version to see what the SBOM looked like.
Importance of Kubernetes Bill of Materials
Like any image you are running in the public cloud this is abstracted of the underlying compute resources that are associated and orchestrating these workloads while Kubernetes has been quickly adopted the risk landscape still stands. Understanding if the underlying cluster you are entrusting to run your scanned images/applications and deployments is safe is a next shift of from code to cloud in security and should be addressed by other vendors its likely you’ll see this expand as SBOM is growing in enterprise adoption given the attacks to the supply chain are proving effective.
References and Additional Resources
https://github.com/kubernetes-sigs/bom
https://thenewstack.io/the-first-kubernetes-bill-of-materials-standard-arrives/
https://blog.aquasec.com/introducing-kbom-kubernetes-bill-of-materials
https://ksoc.com/blog/ksoc-releases-the-first-kubernetes-bill-of-materials-kbom-standard