Add Kubernetes ecosystem #319
Conversation
Signed-off-by: knqyf263 <[email protected]>
docs/schema.md
Outdated
| @@ -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.
As far as I know, there are non-Go projects under the Kubernetes organization. However, I just went through the Kubernetes SIGs organization and found some non-Go projects.
- https://github.com/kubernetes-sigs/blixt
- https://github.com/kubernetes-sigs/nat64
- https://github.com/kubernetes-sigs/security-profiles-operator
I didn't find a document on which organizations the K8s maintainers are responsible, but given that a vulnerability in kubernetes-sigs/azure-file-csi-driver is announced, I presume SIGs projects can issue advisories.
There was a problem hiding this comment.
Hmm, then it seems then the common denominator is just a git repo? i.e.
{
"package": {
"ecosystem": "Kubernetes",
"name": "https://github.com/kubernetes-sigs/blixt"
}
{
"package": {
"ecosystem": "Kubernetes",
"name": "https://github.com/kubernetes/apiserver"
}
There was a problem hiding this comment.
Their primary languages are not Go, but they have go.mod with Go module names.
- https://github.com/kubernetes-sigs/blixt/blob/0858e9284dd1c6c9a46f81b24f9f7d8664c51290/go.mod#L1
- https://github.com/kubernetes-sigs/security-profiles-operator/blob/b6741583f397f1349b5d4b4c30aa680eee2f2065/go.mod#L1
- https://github.com/kubernetes-sigs/nat64/blob/3a0e43b7eacfb60d84ed507b098dcc1501b853a7/go.mod#L1
And there are 184 repositories under kubernetes-sigs, but I found only three non-Go ones. Therefore, it's a very rare case.
"If the component has a Go module name, then the package name is the Go module name. Otherwise, use a git repo."
There was a problem hiding this comment.
Their primary languages are not Go, but they have go.mod with Go module names.
Interesting..
"If the component has a Go module name, then the package name is the Go module name. Otherwise, use a git repo."
In the case of these 3 exceptions, since a go.mod exists, it sounds like should also use the Go module name under this definition?
Since there is no case where there is a no go.mod today, I'd suggest just keeping this simple for now. We can always add additional cases later to the schema when we need them.
There was a problem hiding this comment.
In the case of these 3 exceptions, since a go.mod exists, it sounds like should also use the Go module name under this definition?
Exactly. That's what I wanted to express in the description.
Since there is no case where there is a no go.mod today, I'd suggest just keeping this simple for now. We can always add additional cases later to the schema when we need them.
It sounds reasonable to me. Updated in 01721af.
There was a problem hiding this comment.
happy new year @knqyf263 !
Just following up on your PR once more :)
docs/schema.md
Outdated
| @@ -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?
Signed-off-by: knqyf263 <[email protected]>
Co-authored-by: Oliver Chang <[email protected]> Signed-off-by: Teppei Fukuda <[email protected]>
Signed-off-by: knqyf263 <[email protected]>
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.