-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] add cdx:k8s
taxonomy
#61
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
## `cdx:k8s` Namespace Taxonomy | ||
|
||
| Namespace | Description | | ||
| --- | --- | | ||
| `cdx:k8s:component` | Namespace for metadata of [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/). | | ||
|
||
## `cdx:k8s:component` Namespace Taxonomy | ||
|
||
| Property | Description | | ||
| --- | --- | | ||
| `cdx:k8s:component:type` | Type of the [Kubernetes component](https://kubernetes.io/docs/concepts/overview/components/). Well-known roles are "controlPlane", "node" | | ||
| `cdx:k8s:component:name` | Name of the [Kubernetes component](https://kubernetes.io/docs/concepts/overview/components/). Well-known names are "kube-apiserver", "kube-scheduler", kube-controller-manager", "cloud-controller-manager", "kubelet", "kube-proxy", "dashboard", "cni", "csi" | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you mentioned that the names are not the official ones but different. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry for the long comment.
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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so we really need a set of well-known values in the documentation, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Why is this? I mean, we are scoping for Kubernetes, right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nscuro Is there an improvement you want to suggest?