Update CVE feed layouts for new JSON feed format #38579
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
size/M
|
/cc @PushkarJ @nehaLohia27 |
k8s-ci-robot
added
the
sig/security
|
/hold (AIUI) this change needs to land alongside the matching change to Kubernetes |
k8s-ci-robot
added
the
do-not-merge/hold
|
We thought with @PushkarJ that it would be better to put the caption at the top of the table in order for it to be more noticeable. I took the liberty to add a property of CSS directly in the shortcode HTML template (since the class specified seems not to exist). |
Yes! Why not, I added this stuff 32442ff. |
|
The build error is: |
|
Make sure that the upstream feed includes that change! |
|
Ah you mean the actual build error at the moment? Yes the PRs need each others to work, we have to merge them simultaneously. The best would be to update the script first, it will error the website build when properly generated and then to update the website for the HTML page to be generated correctly. |
k8s-ci-robot
added
the
tide/merge-method-squash
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 2b3c949c61c8e8a1f1e066cdfc228dc1ff979e73
|
|
/remove-label tide/merge-method-squash It's useful to note this history. If there were 22 commits I'd think differently, mind. |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 6a3bbadf9318fb10e5fff6ec43bd292c73e1e6ea
|
|
@mtardy . Are you waiting for another pull request to merge? |
@kbhawkey Not really, I would need someone to approve this one, even though it's currently not building, here's why: |
|
+1 to what @mtardy said |
| [cve_url] | ||
| other = "CVE URL" | ||
| [cve_table_date_before] | ||
| other = "(last updated: " |
There was a problem hiding this comment.
This is a bit unusual
I'll look at how you are constructing the string
There was a problem hiding this comment.
I was thinking on the contrary that it was how we usually do these things, but we can do whatever you think is better.
Lines 275 to 279 in 206231d
There was a problem hiding this comment.
I prefer to have the localized string be a format string:
[cve_table_date_with_label]
other = "(last updated: %s)"and then use a string formatter to include the localized date. That's equivalent, but the placeholder makes it easier for localization teams to understand.
There was a problem hiding this comment.
I'll update this in the follow-up PR #39513 :)
| @@ -1,19 +1,23 @@ | |||
| {{ $feed := getJSON .Site.Params.cveFeedBucket }} | |||
| {{ if ne $feed.version "https://jsonfeed.org/version/1.1" }} | |||
| {{ errorf "Build Failed. CVE feed does not comply with JSON feed v1.1" }} | |||
There was a problem hiding this comment.
Would be better if the build did not fail, but instead use a 'placeholder page' and send an alert (or something like that)
There was a problem hiding this comment.
Ok makes sense. This is a bit in contradiction with this previous review #38579 (review), @sftim do you have an opinion on that as well?
There was a problem hiding this comment.
Sounds like a nice enhancement; however, I would save that for a follow-up PR.
There was a problem hiding this comment.
Yep we'll look at this here #39513 next!
|
Hi, @mtardy . Anyway, the currently published page is: /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kbhawkey The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
The workflow is the following: a script in kubernetes/sig-security is picked up by a job in k8s infra, scheduled to run every 2 hours, and the website retrieves the file created by this job to update its internal JSON data, required to build this page. I just merged the script side, the next job should run at 11:09 CET and then the preview of this PR should work, and the old live page will fail if I do not merge this new one once it picks up the new JSON :) |
|
I tested locally and the web page works with the new output format, let's merge. |
k8s-ci-robot
removed
the
do-not-merge/hold
|
Does this work on website? |
mtardy
force-pushed
the
cve-json-feed
branch
from
7ddf310 to
3305d7b
Compare
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
Related to the following discussion kubernetes#38579 (comment)
Previously it would cause the build to fail, which could lead to confusing situation since the CVE feed comes from outside of the website and could break the workflow. See related discussion: kubernetes#38579 (comment)
Previsouly we were using two data items:
```toml
[cve_table_date_before]
other = "(last updated: "
[cve_table_date_after]
other = ")"
```
Which was simplified, using printf, to:
```toml
[cve_table_date_format_string]
other = "(last updated: %s)"
```
This is related to the following discussion
kubernetes#38579 (comment)
Previously it would cause the build to fail, which could lead to confusing situation since the CVE feed comes from outside of the website and could break the workflow. See related discussion: kubernetes#38579 (comment)
Previsouly we were using two data items:
```toml
[cve_table_date_before]
other = "(last updated: "
[cve_table_date_after]
other = ")"
```
Which was simplified, using printf, to:
```toml
[cve_table_date_format_string]
other = "(last updated: %s)"
```
This is related to the following discussion
kubernetes#38579 (comment)
Previously it would cause the build to fail, which could lead to confusing situation since the CVE feed comes from outside of the website and could break the workflow. See related discussion: kubernetes#38579 (comment)
Previsouly we were using two data items:
```toml
[cve_table_date_before]
other = "(last updated: "
[cve_table_date_after]
other = ")"
```
Which was simplified, using printf, to:
```toml
[cve_table_date_format_string]
other = "(last updated: %s)"
```
This is related to the following discussion
kubernetes#38579 (comment)
Previously it would cause the build to fail, which could lead to confusing situation since the CVE feed comes from outside of the website and could break the workflow. See related discussion: kubernetes#38579 (comment)
5 participants
This PR fixes the layout for the CVE feed for the new JSON format, to be merged after kubernetes/sig-security#75 and kubernetes/sig-security#76 are merged. While these are not merged and deployed, the build will fail because the JSON format is different.
last_updatedroot fields sig-security#76 adds the_kubernetes_io.updated_atroot field used to display the last update date in the caption of the CVE table.Note that PR 75 was merged into PR 76 that bundles all the changes for simplicity.
Note that
{{ getJSON .Site.Params.cveFeedBucket | jsonify }}can look useless but it's to make the JSON file looks "unpretty" like previously (with no space and no indentation). If we don't care about this we can just replace it with{{ os.ReadFile .Site.Params.cveFeedBucket }}. There was some note about this Hugo issue gohugoio/hugo#7229 but I did not encounter this, you can check usingcurlandgrep <to see.Testing this PR locally
Generate the new JSON CVE feed file with the new bash and python scripts from PR 75 and 76, or just download this version generated (with only the four latest CVEs in order to reduce the size of the file) and put the file under
static/official-cve-feed.json.official-cve-feed.jsonextract new version according to PR 75 and 76 as of 2022-12-20T15:12:31Z{ "version": "https://jsonfeed.org/version/1.1", "title": "Auto-refreshing Official CVE Feed", "home_page_url": "https://kubernetes.io", "feed_url": "https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json", "description": "Auto-refreshing official CVE feed for Kubernetes repository", "authors": [ { "name": "Kubernetes Community", "url": "https://www.kubernetes.dev" } ], "_kubernetes_io": { "updated_at": "2022-12-20T15:12:31Z" }, "items": [ { "content_text": "CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)\r\n\r\nA security issue was discovered in Kubernetes where users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them.\r\n\r\nKubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server's private network.\r\n\r\n### Am I vulnerable?\r\n\r\nClusters are affected by this vulnerability if there are endpoints that the kube-apiserver has connectivity to that users should not be able to access. This includes:\r\n\r\n- kube-apiserver is in a separate network from worker nodes\r\n- localhost services\r\n\r\nmTLS services that accept the same client certificate as nodes may be affected. The severity of this issue depends on the privileges & sensitivity of the exploitable endpoints.\r\n\r\nClusters that configure the egress selector to use a proxy for cluster traffic may not be affected.\r\n\r\n\r\n#### Affected Versions\r\n\r\n- Kubernetes kube-apiserver <= v1.25.3\r\n- Kubernetes kube-apiserver <= v1.24.7\r\n- Kubernetes kube-apiserver <= v1.23.13\r\n- Kubernetes kube-apiserver <= v1.22.15\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nUpgrading the **kube-apiserver** to a fixed version mitigates this vulnerability.\r\n\r\nAside from upgrading, configuring an [egress proxy for egress to the cluster network](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) can mitigate this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes kube-apiserver v1.25.4\r\n- Kubernetes kube-apiserver v1.24.8\r\n- Kubernetes kube-apiserver v1.23.14\r\n- Kubernetes kube-apiserver v1.22.16\r\n\r\n**Fix impact:** In some cases, the fix can break clients that depend on the nodes/proxy subresource, specifically if a kubelet advertises a localhost or link-local address to the Kubernetes control plane.\r\n\r\n### Detection\r\n\r\nNode create & update requests may be included in the Kubernetes audit log, and can be used to identify requests for IP addresses that should not be permitted. Node proxy requests may also be included in audit logs.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [email protected]\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Yuval Avrahami of Palo Alto Networks.\r\n\r\n<!-- labels -->\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig api-machinery\r\n/area apiserver", "date_published": "2022-11-08T21:33:26Z", "external_url": "https://www.cve.org/cverecord?id=CVE-2022-3294", "id": "CVE-2022-3294", "summary": "Node address isn't always verified when proxying", "url": "https://github.com/kubernetes/kubernetes/issues/113757", "_kubernetes_io": { "google_group_url": "https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-3294", "issue_number": 113757 } }, { "content_text": "CVSS Rating: [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)\r\n\r\nA security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization.\r\n\r\n### Am I vulnerable?\r\n\r\nClusters are impacted by this vulnerability if all of the following are true:\r\n- There are 2+ CustomResourceDefinitions sharing the same API group\r\n- Users have cluster-wide list or watch authorization on one of those custom resources.\r\n- The same users are not authorized to read another custom resource in the same API group.\r\n\r\n#### Affected Versions\r\n\r\n- Kubernetes kube-apiserver <= v1.25.3\r\n- Kubernetes kube-apiserver <= v1.24.7\r\n- Kubernetes kube-apiserver <= v1.23.13\r\n- Kubernetes kube-apiserver <= v1.22.15\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nUpgrading the kube-apiserver to a fixed version mitigates this vulnerability.\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions.\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes kube-apiserver v1.25.4\r\n- Kubernetes kube-apiserver v1.24.8\r\n- Kubernetes kube-apiserver v1.23.14\r\n- Kubernetes kube-apiserver v1.22.16\r\n\r\n### Detection\r\n\r\nRequests containing `..` in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [email protected]\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit.\r\n\r\n<!-- labels -->\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig api-machinery\r\n/area apiserver\r\n", "date_published": "2022-11-08T21:33:07Z", "external_url": "https://www.cve.org/cverecord?id=CVE-2022-3162", "id": "CVE-2022-3162", "summary": "Unauthorized read of Custom Resources", "url": "https://github.com/kubernetes/kubernetes/issues/113756", "_kubernetes_io": { "google_group_url": "https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-3162", "issue_number": 113756 } }, { "content_text": "CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:L) (5.1, medium)\r\n\r\nA security issue was discovered in kube-apiserver that allows an aggregated API server to redirect client traffic to any URL. This could lead to the client performing unexpected actions as well as forwarding the client's API server credentials to third parties.\r\n\r\nThis issue has been rated medium and assigned CVE-2022-3172\r\n\r\n### Am I vulnerable?\r\n\r\nAll Kubernetes clusters with the following versions that are running aggregated API servers are impacted. To identify if you have aggregated API servers configured, run the following command:\r\n\r\n```shell\r\nkubectl get apiservices.apiregistration.k8s.io -o=jsonpath='{range .items[?(@.spec.service)]}{.metadata.name}{\"\\n\"}{end}'\r\n```\r\n\r\n#### Affected Versions\r\n\r\n- kube-apiserver v1.25.0\r\n- kube-apiserver v1.24.0 - v1.24.4\r\n- kube-apiserver v1.23.0 - v1.23.10\r\n- kube-apiserver v1.22.0 - v1.22.13\r\n- kube-apiserver <= v1.21.14\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nAside from upgrading, no direct mitigation is available.\r\n\r\nAggregated API servers are a trusted part of the Kubernetes control plane, and configuring them is a privileged administrative operation. Ensure that only trusted cluster administrators are allowed to create or modify `APIService` configuration, and follow security best practices with any aggregated API servers that may be in use.\r\n\r\n#### Fixed Versions\r\n\r\n- kube-apiserver v1.25.1 - fixed by #112330\r\n- kube-apiserver v1.24.5 - fixed by #112331\r\n- kube-apiserver v1.23.11 - fixed by #112358\r\n- kube-apiserver v1.22.14 - fixed by #112359\r\n\r\n**Fix impact:** The fix blocks all 3XX responses from aggregated API servers by default. This may disrupt an aggregated API server that relies on redirects as part of its normal function. If all current and future aggregated API servers are considered trustworthy and redirect functionality is required, set the `--aggregator-reject-forwarding-redirect` Kubernetes API server flag to `false` to restore the previous behavior.\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade\r\n\r\n### Detection\r\n\r\nKubernetes audit log events indicate the HTTP status code sent to the client via the `responseStatus.code` field. This can be used to detect if an aggregated API server is redirecting clients.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [email protected]\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Nicolas Joly & Weinong Wang @weinong from Microsoft.\r\n\r\nThe issue was fixed and coordinated by Di Jin @jindijamie @enj @liggitt @lavalamp @deads2k and @puerco.\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig api-machinery\r\n/area apiserver\r\n/triage accepted", "date_published": "2022-09-16T13:14:50Z", "external_url": "https://www.cve.org/cverecord?id=CVE-2022-3172", "id": "CVE-2022-3172", "summary": "Aggregated API server can cause clients to be redirected (SSRF)", "url": "https://github.com/kubernetes/kubernetes/issues/112513", "_kubernetes_io": { "google_group_url": "https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-3172", "issue_number": 112513 } }, { "content_text": "A security issue was discovered in Kubernetes that could allow Windows workloads to run as `ContainerAdministrator` even when those workloads set the `runAsNonRoot` option to `true`.\r\n\r\nThis issue has been rated low and assigned CVE-2021-25749\r\n\r\n### Am I vulnerable?\r\n\r\nAll Kubernetes clusters with following versions, running Windows workloads with `runAsNonRoot` are impacted\r\n\r\n#### Affected Versions\r\n\r\n- kubelet v1.20 - v1.21\r\n- kubelet v1.22.0 - v1.22.13\r\n- kubelet v1.23.0 - v1.23.10\r\n- kubelet v1.24.0 - v1.24.4\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThere are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet v1.22.14\r\n- kubelet v1.23.11\r\n- kubelet v1.24.5\r\n- kubelet v1.25.0\r\n\r\n\r\nTo upgrade, refer to this documentation _For core Kubernetes:_ https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/\r\n\r\n### Detection\r\n\r\nKubernetes Audit logs may indicate if the user name was misspelled to bypass the restriction placed on which user is a pod allowed to run as.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [email protected]\r\n\r\n#### Additional Details\r\n\r\nSee the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/112192 \r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported and fixed by Mark Rosetti (@marosset)\r\n", "date_published": "2022-09-01T21:02:01Z", "external_url": "https://www.cve.org/cverecord?id=CVE-2021-25749", "id": "CVE-2021-25749", "summary": "`runAsNonRoot` logic bypass for Windows containers", "url": "https://github.com/kubernetes/kubernetes/issues/112192", "_kubernetes_io": { "google_group_url": "https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25749", "issue_number": 112192 } } ] }Modify
config.tomlto use the local file.Preview
The HTML page looks very similar with just a new caption indicating the last update date.