Kubernetes vulnerability dashboard

[tallclair]

Should we have a central place where kubernetes security vulnerabilities are published? Our current announcement template includes a lot of mailing lists, and discuss.kubernetes.io. We also usually file a github issue with more details on the vulnerability.

Some ideas include:

• (current process) just use kubernetes-security-announce history
• Create a security bulletin on the website (something similar to GKE security bulletins or AWS security bulletins)
• Use github
  • File github issues with a dedicated label
  • File github issues in a dedicated repo
  • Leverage GitHub security advisories?

/help

[k8s-ci-robot]

@tallclair:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

Should we have a central place where kubernetes security vulnerabilities are published? Our current announcement template includes a lot of mailing lists, and discuss.kubernetes.io. We also usually file a github issue with more details on the vulnerability.

Some ideas include:

• (current process) just use kubernetes-security-announce history
• Create a security bulletin on the website (something similar to GKE security bulletins or AWS security bulletins)
• Use github
  • File github issues with a dedicated label
  • File github issues in a dedicated repo
  • Leverage GitHub security advisories?

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tallclair]

A few notes on github security advisories:

• Require repo admin privileges to create
• I think advisories cannot be edited or amended once published
• There is an atom feed (and API) associated with a repo's security advisories, so they could suffice as a dashboard & feed

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tallclair]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[tallclair]

/remove-lifecycle rotten

[tallclair]

/cc @justaugustus

An approach to a vulnerability dashboard that we discussed: add a new kind/cve label, and ensure that CVE patches get a release note along the lines of kubernetes/kubernetes#92941:

CVE-2020-8559 (Medium): Privilege escalation from compromised node to cluster. See kubernetes/kubernetes#92914 for more details.

Then, leverage https://relnotes.k8s.io/ filtered by kind/cve as the vulnerability dashboard.