Add Kubernetes ecosystem #319
Conversation
Signed-off-by: knqyf263 <knqyf263@gmail.com>
| @@ -706,6 +717,7 @@ The defined ecosystems are: | |||
| | `Go` | The Go ecosystem; the `name` field is a Go module path. | | |||
| | `Hackage` | The Haskell package ecosystem. The `name` field is a Haskell package name as published on Hackage. | | |||
| | `Hex` | The package manager for the Erlang ecosystem; the `name` is a Hex package name. | | |||
| | `Kubernetes` | The Kubernetes ecosystem; the `name` field is a Kubernetes component name. | | |||
There was a problem hiding this comment.
Is there some documentation we can point to as an authoritative reference for what a component name is and how to format it?
There was a problem hiding this comment.
To clarify this comment a bit more using your example in kubernetes-sigs/cve-feed-osv#9 (comment):
It's unclear if the name should be "kube-apiserver", or "k8s.io/apiserver". Is there some clarification we can make here on the expected naming scheme?
There was a problem hiding this comment.
Hello @oliverchang, sorry for the late reply. I had been on vacation, and I've missed your comment in accumulated tasks.
Actually, I would like to discuss this point: I thought it would be difficult to distinguish apiserver from non-upstream apiserver if we use apiserver, so I adapted it to Go's module name, like k8s.io/apiserver to clarify it's upstream, but it is not yet strictly defined. How can we distinguish between different flavors within the same ecosystem in the OSV schema?
There was a problem hiding this comment.
We have the convention of having a ":SUFFIX" qualifier for ecosystem names.
For example, for Debian:
The Debian package ecosystem; the name is the name of the source package. The ecosystem string might optionally have a :
<RELEASE>suffix to scope the package to a particular Debian release.<RELEASE>is a numeric version specified in the Debian distro-info-data. For example, the ecosystem string “Debian:7” refers to the Debian 7 (wheezy) release.
Would something similar make sense for Kubernetes?
"Kubernetes" refers to upstream
"Kubernetes:<distribution>" refers to a specific distribution?
There was a problem hiding this comment.
It sounds reasonable. Should we define a list of <distribution> here? It seems difficult to list all the K8s distributions, so can we simply show an example, like “Kubernetes:<distribution>”, e.g. “Kubernetes:GKE” or something like that?
There was a problem hiding this comment.
Thanks!
I'm unfamiliar with GKE advisories, so I don't know any other ones unfortunately. For GKE, Rancher, do they have machine readable ways to refer to specific Kubernetes components? The closest machine readable feed I've found is https://cloud.google.com/feeds/gke-security-bulletins.xml which is just an Atom feed with human readable data.
If these don't exist, maybe we should just start with plain "Kubernetes" to refer to upstream for now, and clarify it in the schema text?
We still need to have clearly defined rules for what "name" is though... Would having the name be the Go module name (i.e. k8s.io/apiserver) be the best way to encode upstream Kubernetes vulnerabilities (with the caveat that version numbers are different from the Go module as you pointed out here)? Or, is there some other authoritative list on how to name upstream Kubernetes components?
Then later, perhaps we can work with other GKE feeds to see if they can provide more machine readable feeds and get their agreement on how to format their distro feeds in OSV?
There was a problem hiding this comment.
As far as I know, there are no machine-readable feeds. That's why we started https://github.com/kubernetes-sigs/cve-feed-osv with its definition.
If these don't exist, maybe we should just start with plain "Kubernetes" to refer to upstream for now, and clarify it in the schema text?
I agree.
Would having the name be the Go module name (i.e. k8s.io/apiserver) be the best way to encode upstream Kubernetes vulnerabilities (with the caveat that version numbers are different from the Go module as you pointed out kubernetes-sigs/cve-feed-osv#9 (comment))?
Another problem with Go module names is that the component not written in Go will not fit. We may want to take a list from the official document.
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
- cloud-controller-manager
- kubelet
- kube-proxy
However, it's inconsistent with module names, kube-apiserver vs k8s.io/apiserver, and kube-scheduler vs k8s.io/kube-scheduler. I'm not sure which is better.
There was a problem hiding this comment.
Hmm, the official document doesn't seem to list all the possible components from past Kubernetes CVEs.
e.g.
- ingress-nginx: CVE-2024-7646: Ingress-nginx Annotation Validation Bypass kubernetes/kubernetes#126744
- azure-file-csi-driver: CVE-2024-3744: azure-file-csi-driver discloses service account tokens in logs kubernetes/kubernetes#124759
- kubectl: CVE-2019-11251: kubectl cp symlink vulnerability kubernetes/kubernetes#87773
I couldn't find any other document that comprehensively lists this either. It seems better to me to use the Go module names since they already exist and are consistent.
e.g. k8s.io/ingress-nginx, sigs.k8s.io/azurefile-csi-driver, k8s.io/kubectl
WDYT?
There was a problem hiding this comment.
It seems better to me to use the Go module names since they already exist and are consistent.
Yes, that's the conclusion we also made when we started cve-feed-osv.
Another problem with Go module names is that the component not written in Go will not fit.
What do you think about this problem? We also considered it but didn't develop a better solution than Go module names. Then, we decided to go with module names. I think it's a good time to discuss it with the OSV team.
There was a problem hiding this comment.
happy new year @knqyf263 !
Just following up on your PR once more :)
| @@ -706,6 +717,7 @@ The defined ecosystems are: | |||
| | `Go` | The Go ecosystem; the `name` field is a Go module path. | | |||
| | `Hackage` | The Haskell package ecosystem. The `name` field is a Haskell package name as published on Hackage. | | |||
| | `Hex` | The package manager for the Erlang ecosystem; the `name` is a Hex package name. | | |||
| | `Kubernetes` | The Kubernetes ecosystem; the `name` field is a Kubernetes component name. | | |||
There was a problem hiding this comment.
To clarify this comment a bit more using your example in kubernetes-sigs/cve-feed-osv#9 (comment):
It's unclear if the name should be "kube-apiserver", or "k8s.io/apiserver". Is there some clarification we can make here on the expected naming scheme?
Adding
Kubernetesecosystem according to the discussion here.This PR does not specify how to handle Kubernetes distributions by cloud vendors like EKS and GKE. We can talk about it here if needed, or merge it once and discuss it separately.