project-codeflare / instascale

On-demand Kubernetes/OpenShift cluster scaling and aggregated resource provisioning
Apache License 2.0
10 stars 19 forks source link

instascale-controller:latest image has existing vulnerabilities #33

Closed jbusche closed 1 year ago

jbusche commented 1 year ago

I used twistlock to scan the instascale-controller:latest image, and it has a few known vulnerabilities:

6 total vulnerabilties 
4 High
2 Medium

I tried changing the Dockerfile to use the latest golang image:

#FROM golang:1.17 as builder
FROM golang:1.20.1 as builder

And that fixed all the vulnerabilities but one: https://nvd.nist.gov/vuln/detail/CVE-2022-21698

Looking to see how that can potentially be solved tomorrow. Full description of the issue is below:

packagePath = /manager packageName = github.com/prometheus/client_golang packageVersion = v1.11.0 status = fixed in 1.11.1 description = client_golang is the instrumentation library for Go applications in Prometheus, and the promhttp package in client_golang provides tooling around HTTP servers and clients. In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods. In order to be affected, an instrumented software must use any of promhttp.InstrumentHandler* middleware except RequestsInFlight; not filter any specific methods (e.g GET) before middleware; pass metric with method label name to our middleware; and not have any firewall/LB/proxy that filters away requests with unknown method. client_golang version 1.11.1 contains a patch for this issue. Several workarounds are available, including removing the method label name from counter/gauge used in the InstrumentHandler; turning off affected promhttp handlers; adding custom middleware before promhttp handler that will sanitize the request method given by Go http.Request; and using a reverse proxy or web application firewall, configured to only allow a limited set of methods.

jbusche commented 1 year ago

Before the changes: twistlock-scan-results-instscale-latest.results.csv

After the changes: (Empty, no issues) twistlock-scan-results-20230216-194159-699816235-UTC-9f3a5ef7.results.csv

asm582 commented 1 year ago

@jbusche quay has an image scan, curious to know how twistlock scan is different from image scans done by quay repo?

jbusche commented 1 year ago

@asm582. I was given access to quay, and I see their security scan. It can't be a very thorough scan, it only found one item on some of the mcad-controller images I looked at (main-v1.29.50 and older.) And the Quay security scan is showing "unsupported" for the instascale-controller images, for some reason. (Meanwhile, with Twistlock it found 44 fixable vulnerabilities for the mcad-controller:main-v1.29.50, and six for instascale.)

We started using Twistlock to scan our containers a few years ago when I was in the Watson org - it was required to have no Critical or High vulnerabilities before we moved any containers to production. Twistlock got bought by PaloAlto Networks https://www.ibm.com/partners/showcase/solutions/solution/panw-prisma-cloud-compute. It's useful to scan an image/container to make sure there's no old libraries in there. It was very helpful during the ilog4J debacle in Dec 2021, and it immediately catches old openssl and java, go, etc, with links to the CVE website and a nice description of the problem it's found (if any.)

One problem with any code is it can go out of compliance from one day to another. But as we're coming out with new releases, we can hopefully address the new problems as they come up, and feel better that our latest images don't contain known vulnerabilities.

jbusche commented 1 year ago

Fixed and merged in PR 34