to my understanding, "controlPlane" and "node" are not types of a component, but workers that are defined as such are able to run specific components.

why do you need to make this clear in the first place?
if i knew a components role (like "kubelet") i would know on which runner-type this should be running (like "node").
there is no need to announce directly implied data, right?

could you describe why this information is useful?

the use of this field is just for information management, so that a user can search the control plane components or ignore them, etc. yes we don't mind removing it in the initial PR.

about your comment: for node-level components I think you're right and in fact we represent this as a dependency in the SBOM we generate. for control plane, there isn't an entity to refer to, we actually has a version with a controlplan entiry in the sbom just for the hierarchy but eventually decided to use property instead.

I agree with @itaysk in that there is value in stating the component type explicitly. If the tool generating the KBOM is able to deduce the type, why should the receiving party have to do it again?

The distinction of control plane vs. node is most certainly something the receiving party is interested in.

The distinction of control plane vs. node is most certainly something the receiving party is interested in.

@nscuro Is there an improvement you want to suggest?

you mentioned that the names are not the official ones but different.
The official ones do have documentation and I would recognize them. Your custom values have no documentation at all.
what is the benefit in custom values?

Sorry for the long comment.
I think this document does not intend to be the source of truth for how to classify or name components and it's not comprehensive nor up to date. Also, it is written as an article and not a technical document and therefore I don't think the titles used there should be taken verbatim as canonical names. For example:

1. some of the components like kube-apiserver or cloud-controller-manager are written in a technical standard, while some like Web UI (Dashboard) or Container Resource Monitoring are written in a human readable standard. Also some titles like "Logging" or "Monitoring" aren't grammatically fitting for a component role or type. I think offering the latter as well known is inconsistent and potentially confusing.
2. "Network Plugins" is a good for a doc title in but the technical term generally used is CNI Plugin (container network interface). This is used in other parts of the k8s docs and in other k8s tools. The doc covers CNI but not CSI (container storage interface) which is a more recent addition. If we chose the doc title "Network Plugin" should we call the other one "Storage Plugin" to go with the theme? probably not.
3. Web UI (dashboard) - again, decent title in an web page, but I don't think it's useful in a json document.
4. Addons is an entire rabbit hole of inconsistency and ill defined concepts. Addons used to be a k8s feature (there was an "addon-manager" and a collection of addons) but this is no longer. Now addon is an abstract concept which has conflicting definitions: the k8s docs refer to addons as k8s components in kube-system namespace, but the addons listed in the same don't follow this definition. most kubernetes utilities today (that could have been "addons") are being distributed and installed by users however they want and aren't called addons anymore. so for us, we decided against trying to fix this problem and just ignore it.

IMO - besides the "very well known" components (apiserver, kubelet, etc) I think it will be very hard to map components to a common taxonomy (for example, is this app I found a k8s dashboard or just an admin tool you happen to have there) and it's also not a problem we're trying to solve right now.

I can restore my original version with the titles from doc, or keep just the "very well known" components, up to you.

Agreed, the naming scheme used by the linked document is inconsistent and there exist better, technical names that are widely used in the industry.

For cni and csi specifically though, I'd suggest to use cni-plugin and csi-plugin instead. CNI and CSI are just interfaces exposed by k8s, whereas what you'd list in a KBOM are implementations of it (e.g. Calico, Cilium).

so we really need a set of well-known values in the documentation, right?
Would you add one, so we can discuss it?

Agreed, the naming scheme used by the linked document is inconsistent and there exist better, technical names that are widely used in the industry.

Why is this? I mean, we are scoping for Kubernetes, right?
How comes the terms from the docs of Kubernetes are inconsistent, and why are there technical names that are widely used in the industry instead?
Could somebody explain and help me understand, whether we are still in the technical scope of Kubernetes, not in general container scope?