[PROPOSAL] general purpose kubernetes taxonomy KBOM

[itaysk]

We're working on mapping Kubernetes clusters composition as BOM (aka "KBOM"). For that, we want to use properties to designate cluster components roles, and attributes that are meaningful to understanding the cluster composition.
For example, here's a snippet from generated KBOM that describes a Kubernetes API Server component:

{
      "bom-ref": "e86fd8d5-c302-4c44-b1b2-833b97540f13",
      "type": "application",
      "name": "kube-apiserver-kind-control-plane",
      "properties": [
        {
          "name": "aquasecurity:trivy:SchemaVersion",
          "value": "0"
        },
        {
          "name": "aquasecurity:trivy:k8s:controlplane_components",
          "value": "apiserver"
        }
      ]
}

We're proposing to register a kubernetes namespace for the Kubernetes-specific metadata.
As for usage, for now, we are following the Kubernetes taxonomy as defined here: https://kubernetes.io/docs/concepts/overview/components/
Which means we will add:

1. kubernetes:controlplane_component
2. kubernetes:node_component
3. kubernetes:addon

If this is acceptable, I'll create a PR with the namespace reservation and initial documentation.

[jkowalleck]

i like the idea in general, but ...
my thoughts:

• who would own this kubernetes namespace, then? Is there any org or a general committee? did you get in touch with kubernetes(Cloud Native Computing Foundation), maybe they have such a thing already?
• where is the taxonomy for this namespace? just having it registered/reserved and having no FFA taxonomy, that serves no purpose. So as long as there is no peer-reviewed and general agreed taxonomy details, i'd veto this proposal.
• I am concerned that this would create a non-standard nobody would use, so there should be consensus about the details of this taxonomy, first.

[stevespringett]

@jkowalleck one possibility is to put this under the cdx namespace in the same way we support maven, go, and npm today.

[itaysk]

Thanks for the feedback. I'll follow your guidance here. I could kickstart the discussion with the kubernetes community if needed but if you think a cdx subsection is better that's fine with us.

[jkowalleck]

@itaysk, would you draft a pullrequest introducing the namespace cdx:kubernetes?
This could kick-start a discussion about details and help anybody to understand your idea and goals.

FYI for the container images there is a similar request for standardization: #36

[jkowalleck]

KSOK also has a Kubernetes taxonomy: https://github.com/ksoclabs/kbom/blob/main/docs/taxonomy.md
I asked for corporation to join efforts

[jkowalleck]

see also:
https://blog.aquasec.com/introducing-kbom-kubernetes-bill-of-materials

[itaysk]

+1 we (Aqua Trivy) would love to collaborate on this.
From quick look the KSOC taxonomy, it seems there's no overlap with what Trivy defined, which is be a good thing since it will be easy to agree :)

[jkowalleck]

just saw the title, thought this might help here:
https://blog.aquasec.com/scanning-kbom-for-vulnerabilities-with-trivy

[itaysk]

Thanks for picking this up. I should mention that in the process to develop vulnerability scanning on top of our KBOM, we changed our KBOM to show Kubernetes components as first class CDX components instead of as properties of other components (such as Pods).
For example, the Kind API-Server example from the issue description now looks like:

    {
      "bom-ref": "pkg:k8s/k8s.io%2Fapiserver@1.21.1",
      "type": "application",
      "name": "k8s.io/apiserver",
      "version": "1.21.1",
      "purl": "pkg:k8s/k8s.io%2Fapiserver@1.21.1",
      "properties": [
        {
          "name": "aquasecurity:trivy:resource:Name",
          "value": "kube-apiserver-kind-control-plane"
        },
        {
          "name": "aquasecurity:trivy:resource:Type",
          "value": "controlPlane"
        }
      ]
    },

We are still experimenting and might tweak this more, but this feels like a better approach for us.

For now I wouldn't mind closing this issue, until there's clear motivation to reopen it. If that happens I would bring more opinionated suggestion and backing from Kubernetes and the community.