-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
Sustainable solution to maintaining links to 3rd party content #32778
Comments
From https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04/page/567IC, between Mar 7 - Apr 5, 2022:
|
Some thoughts
/remove-kind bug |
Maybe the folks behind the CNCF landscape might be able to help us out here / we can draw on that existing work? The CNCF landscape is another kind of curated list; it's maintained; there are lots of projects. I do have a feeling that there are still lots of projects (client libraries, network plugins, container runtimes, the list goes on) that aren't in the landscape. As Kubernetes' wider ecosystem grows, a path that involves the CNCF landscape might well be the way forward. |
+1 to use the CNCF landscape but it will act as a gatekeeper Another thought I had is to remove all links on the cluster-admin/addons and cluster-admin/networking page and keep a short summary of the plugins. Users can search for the appropriate repo and docs for the plugin on their own. |
I'm in favor of delegating to the CNCF landscape. FWIW, you can filter to CNI projects for the sake of the cluster-admin/networking page: https://landscape.cncf.io/card-mode?category=cloud-native-network&grouping=category (though there is not complete overlap with our list) |
/triage accepted |
Also relates to #20607 |
/priority important-longterm |
I can take a look, update some links and update docs. |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
/triage accepted
|
/assign |
The Security Response Committee gets a fair amount of reports about link hijacking, which is basically what you get when a third party project we were linking to disappears or changes its name (surprisingly common...)
We just got a big dump of reports about links on https://kubernetes.io/docs/concepts/cluster-administration/addons/ and https://kubernetes.io/docs/concepts/cluster-administration/networking/. This is a problem because not only are we drawing from our bug bounty fund to pay out bounties for these, but it also increases the load on the security response committee to validate, triage & follow up on these issues.
Brainstorming some possible solutions:
Other ideas?
/sig security docs
/committee security-response
The text was updated successfully, but these errors were encountered: