Sustainable solution to maintaining links to 3rd party content

[tallclair]

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:

1. Exclude these from the bug bounty - Not ideal, as this is still a bad user experience at best, and an attack vector at worst.
2. Eliminate or reduce external links - Probably the best solution when it's feasible, but not good when the links are providing value to the users.
3. Better detection of removed content - I believe we already have some form of broken link detection in place, but that doesn't work when a domain falls back to the domain registrar (e.g. a "buy this domain" page). An engineering solution could be to cache the TLS certificates, and flag the link for manual review (file an issue?) when the certificate changes. I don't know how much churn this would generate from legitimate cert rotation though.

Other ideas?

/sig security docs
/committee security-response

[tallclair]

From https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04/page/567IC, between Mar 7 - Apr 5, 2022:

• https://kubernetes.io/docs/concepts/cluster-administration/networking/ is the 72nd most popular page, with 26,261 page views
• https://kubernetes.io/docs/concepts/cluster-administration/addons/ is the 138th most popular page, with 12,695 page views

[sftim]

Some thoughts

• as a personal opinion, I think it's OK not to pay buy bounties about the URLs of third party projects that we hyperlink to
  • if we hyperlink to a web page and that thing we link to is compromised by other means, eg they commit their release key and push it, that's also not a bug bounty where the Kubernetes project would pay out
  • I have a feeling that, technically, we hyperlink to every CNCF landscape project
• there might be a service that can open GitHub issues when pages we link to expire and are replaced with lookalikes or with holding pages
• the existing third party software disclaimer does state “The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically”, but we could reword it or even link to a page that clarifies the lack of responsibility
• maybe there is a reputable-enough list of network plugins and / or cluster add-ons that folks might want to use
  • we could hyperlink to that list, whilst retaining the disclaimer that we're not responsible for the list of contents
• we used to provide instructions on setting up a cluster that included details for common network plugins; we no longer do, and I wonder if that means that folks are instead following external guides more.
  • if the outcome of that is that more people using Kubernetes are relying on docs we don't own at all, does that actually help achieve the outcome we want in terms of helping people run secure clusters?

/remove-kind bug
(not sure what this is, we might add that label back as we triage this)
/lifecycle frozen
/language en

[sftim]

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.

[reylejano]

+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.

[tallclair]

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)