KEP-3203: Auto-refreshing official CVE feed

Implementation History
BETA Implementable
Created 2022-02-01
Latest v1.27
Milestones
Alpha v1.25
Beta v1.27
Stable TBD
Ownership
Owning SIG
SIG Security
Participating SIGs
SIG K8s InfraSIG TestingSIG DocsSIG Security
Primary Authors
@PushkarJ

KEP-3203: Auto-Refreshing Official CVE Feed

Release Signoff Checklist

Items marked with (R) are required prior to targeting to a milestone / release .

  • (R) Enhancement issue in release milestone, which links to KEP dir in kubernetes/enhancements (not the initial KEP PR)
  • (R) KEP approvers have approved the KEP status as implementable
  • (R) Design details are appropriately documented
  • (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
    • e2e Tests for all Beta API Operations (endpoints)
    • (R) Ensure GA e2e tests for meet requirements for Conformance Tests
    • (R) Minimum Two Week Window for GA e2e tests to prove flake free
  • (R) Graduation criteria is in place
  • (R) Production readiness review completed
  • (R) Production readiness review approved
  • “Implementation History” section is up-to-date for milestone
  • User-facing documentation has been created in kubernetes/website , for publication to kubernetes.io
  • Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes

Summary

Currently it is not possible to filter for issues or PRs that are related to CVEs announced by kubernetes. This KEP addresses this concern by labeling these issues or PRs with the new label official-cve-feed using the automation. The in-scope issues are the closed issues for which there is a CVE ID and is officially announced as a Kubernetes CVE by SRC in the past.

Motivation

With the growing number of eyes on Kubernetes, the number of CVEs related to Kubernetes have increased. Although most CVEs that directly, indirectly, or transitively impact Kubernetes are regularly fixed, there is no single place for the end users of Kubernetes to programmatically subscribe or pull the data of fixed CVEs. Current options are either broken or incomplete .

An auto-refreshing CVE feed will allow end users to programmatically fetch the list of CVEs and allow them to get the latest information from Kubernetes community.

Goals

Create a periodically auto-refreshing, machine-readable list of official Kubernetes CVEs

Non-Goals

  • Triage and vulnerability disclosure: This will continue to be done by SRC
  • Listing CVEs that are identified in build time dependencies and container images. Only official CVEs announced by the Kubernetes SRC will be published in the feed.
  • Integration with CVEProject may happen at a future stage but currently is not planned or scoped.

User Stories (Optional)

Story 1

As a K8s end user, I want a list of CVEs with relevant information that I can fetch programmatically, so I can track when new CVEs are announced.

Story 2

As a K8s End User, I want to use my browser to get a list of fixed CVEs, from the official K8s website so that I can trust it as an authoritative source of data through implicit trust offered by website certificate and domain name.

Story 3

As a K8s maintainer, I want to create a process that auto-updates CVE feed, when SRC announces new CVEs such that I do not have to do extra work to maintain this feed manually

Story 4

As a K8s platform provider, I want to automatically know if my Kubernetes clusters are vulnerable to any of the CVEs SRC have announced. I want to have a programmatically available API to parse this kind of data so I can easily provide it to users of my platform.

Proposal

Pre-requisites

Overview

  • Generate a JSON blob using the results from the filtered label on k/k repo.
  • Create a Prow job to periodically generate this JSON blob.
  • Push this JSON blob when needed (e.g. when a new CVE is announced) to GCS ( Google Cloud Bucket)
  • Using Hugo and other tooling (such as Netlify), publish the list from this JSON blob on official k8s website during k/website build
  • Generate an RSS feed (atom format) with hugo templates using the generated JSON blob

Risks and Mitigations

JSON blob construction will fail

If the generation of the JSON blob listing known CVEs were to fail, downstream jobs also fail. If blob construction fails, the failure will alert the owners of this feature and we will take action as needed. If the failure can not be fixed in a reasonable amount of time, the CVE feed will be stale until it is fixed. In case of an urgent need from the community to update the vulnerabilities feed, JSON blob will be manually updated via gsutil command.

Misuse of Auto-Refresh feature

Without proper filtering and control over who can label GitHub issues, the list of CVEs can become a list with poor signal-to-noise ratio making the list unusable.

For this purpose, the filtering is applied such that only issues that are marked as closed will be part of the list. Also, additionally, the official-cve-feed label is a restricted label that can only be applied by SRC and SIG Security Tooling Leads.

Large JSON blob could lead to slower read/write and resource consumption

Blobs will only be rewritten, if the generated blob is different from existing blob. As hash file would be created and stored alongside generated blob. This hash file will be check everytime before push to the hash of the generated file. If the hash file matches writing to the bucket will be skipped, if hash file is different writing to bucket, will be triggered.

Design Details

The steps to implement this design will involve a prow job that:

  1. Queries Github API for fixed official CVEs
  2. Generates a JSON blob based on the query results
  3. Writes the JSON blob to gcs-bucket if it is different than existing blob
  4. Triggers the k/website build using netlify build-hook . Secret token to trigger build is added as External Secret. See example for snyk-token
  5. k/website build pulls the JSON blob from gcs bucket during website rebuild, pulling it from gcs-bucket into something like https://kubernetes.io/security/official-cve-feed.json
  6. k/website renders the JSON blob as an HTML table for viewing the list of fixed CVEs from a browser at this location: https://kubernetes.io/docs/reference/issues-security/official-cve-feed and linked from this page: https://kubernetes.io/docs/reference/issues-security/security/

Notes:

  • A GCS bucket needs to be created. Example PR for this looks like this
  • Additional custom fields need to be added to make JSON feed compliant with https://validator.jsonfeed.org/

Test Plan

This is a process KEP implemented using periodic prow job. This KEP is not implemented for any functional use cases of kubernetes. So no e2e/unit/integration tests are applicable and going forward test plan will mostly include the scenarios around monitoring of the prow job for any failures as and when needed.

Graduation Criteria

Alpha

  • Feature implemented with working JSON feed and tabular list
  • Initial e2e testing completed and alerting setup for detecting failures

Beta

  • Gather feedback from developers and end users
  • Make JSON feed compliant with jsonfeed spec
  • Add RSS feed for the CVE list
  • Add fields that signal freshness of the data

Upgrade / Downgrade Strategy

Not applicable

Version Skew Strategy

Not applicable

Production Readiness Review Questionnaire

Not applicable as per this comment

Implementation History

Drawbacks

Alternatives

Storage of CVE feed blob

There are two options to store the CVE feed JSON blob:

1. Only use Google Cloud Bucket

A new Google cloud bucket can be created where the CVE feed is written using gsutil tool and read via curl call.

  • Advantages:
    • Transparent updates to JSON blob where the prow job run will be identical everytime.
    • Access control for writing to bucket is least privilege i.e. managed via a service account and Google group membership
  • Disadvantages:
    • CVE list has an unofficial looking URL which would be hard for an end user to decipher for its authenticity and provenance.

2. Only use Git Repository

Store it as a version controlled artifact in one of the kubernetes GitHub Org repositories.

  • Advantages:

    • When a Git Repository especially k/website hosts the JSON blob the domain name in the URL would be k8s.io/static/security/official-cve-feed.json which is much more recognizable, intuitive in terms of trust, TLS enabled and unlikely to be spoofed. But there are several disadvantages:

  • Disadvantages:

    • This might get delayed by PR review and approval process. However, this can be prevented through use of skip-review label.
    • A fork would need to be maintained under a Github Robot for k/website or k/sig-security which will add overhead for GitHub Admins who manage the robot accounts and its forks.

In summary, because both the approaches have pros and cons, the finalized approach combined the good parts from both the alternatives by storing the blob in Google Cloud bucket but rendering it via kubernetes/website GitHub Repository.

Infrastructure Needed (Optional)

A GCS bucket to store JSON blob is needed, with its corresponding service account.