[YUNIKORN-1535] Use scratch base image for admission and scheduler docker images

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Fix Version/s: 1.3.0
• Component/s: core - scheduler
• Labels: pull-request-available release-notes
• Target Version: 1.3.0
• Assignee: Craig Condit
• Reporter: Sahib Aulakh
• Created: 10/Jan/23 19:56
• Updated: 20/Jun/23 14:41
• Resolved: 03/Apr/23 12:21

Description

We are seeing spurious CRITICAL issues raised by Twistlock when scanning YuniKorn admission and scheduler images. This can be avoided by changing the base image from alpine to scratch.

 

More details on this issue in the Slack discussion below:

 

Twistlock scan of Yunikorn

This pertains to the CRITICAL issues surfaced by Twistlock on the YuniKorn image.

Question on Slack Channel (https://yunikornworkspace.slack.com/archives/CLNUW68MU/p1673369962230479)

For a client in the financial industry, in order to use Yunikorn, we have to pass the security scans from Twistlock (https://www.cloudfoundry.org/the-foundry/twistlock/). Twistlock is currently raising the following issues at CRITICAL level for the following images:

admission-1.1.0, scheduler-1.1.0

================================

(1) https://nvd.nist.gov/vuln/detail/CVE-2022-37434 (zlib)

(2) https://nvd.nist.gov/vuln/detail/CVE-2022-2068 (libssl1.1, libcrypto1.1)

 

web-1.1.0

=========

(3) https://nvd.nist.gov/vuln/detail/CVE-2022-42915 (libcurl, curl)

(4) https://nvd.nist.gov/vuln/detail/CVE-2022-32221 (libcurl, curl)

 

I need some advice as to how to make progress here:

(a) For (1), is it sufficent to say that the API call inflateGetHeader is not being made in YK code, so this issue is not relevant? Is it sufficient to search for "inflateGetHeader" in YK sources to verify that the call is not being made anywhere by YK code? I am assuming that the C programming API is not being renamed somewhere.

(b) For (2), is it sufficent to say that the offending shell command "c_rehash" is not being exercised anywhere in the YK code base?

(c) For (3), the offending command is curl before 7.86.0. Is it sufficient to say that curl is not being exercised in the manner indicated in the CVE?

(d) For (4), again can we rule out this scenario for Yunikorn?

(e) Fixes for all these issues exist in later versions of zlib, libssl, libcrypto, libcurl and curl. How much work is involved in switching to these later versions of the libraries? I can supply the additional details here.

 

(f) Finally, if I were to undertake this task and create git pull request, can someone from YK team work with me and provide some basic guidance? I have extensive programming experience but am new to Go.

Response from Craig Condit from YuniKorn team

For #1 and #2 vulnerabilities, YuniKorn is not affected. The yunikorn scheduler and admission controller components are the only things that run within the generated containers, and both are static go executables which do not make use of the affected libraries. It's likely they are being triggered due to libraries / binaries included in the base alpine images. For #3 and #4, the web image uses nginx internally, which does not use curl / libcur.

To prevent issues like #1/#2 in the future, we should probably look at moving the scheduler images to use the scratch (basically empty) base image. This would limit any potential surface area to the YK binary itself. For #3/#4, we need nginx, so we'll need to keep updating to newer nginx-alpine images.

Issue Links

• is duplicated by: YUNIKORN-1536 Avoid spurious Twistlock flags when scanning web package
• relates to: YUNIKORN-1672 Use go webserver instead of nginx
• links to: GitHub Pull Request #564