new Dockerfile for Kong 0.11.0 Alpine

[shashiranjan84]

No description provided.

[tianon]

Looks like the only change is the addition of apk upgrade -- any particular reason for adding this?

See also the bit in https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#apt-get about apt-get upgrade, which applies similarly here:

You should avoid RUN apt-get upgrade or dist-upgrade, as many of the “essential” packages from the parent images won’t upgrade inside an unprivileged container. If a package contained in the parent image is out-of-date, you should contact its maintainers. If you know there’s a particular package, foo, that needs to be updated, use apt-get install -y foo to update automatically.

Our systems will auto-rebuild the kong image any time there is an update to the alpine:3.6 base image.

[shashiranjan84]

@tianon We did that based on this recommendation
.

[shashiranjan84]

@tianon Basically we want to use updated zlib package from Alpine image.

[p0pr0ck5]

@tianon we are trying to resolve three "critical" vulnerabilities in our docker image according to the docker store security scan. It reports that zlib, PCRE, and perl all have critical vulnerabilities, yet as you can see we are using all upstream packages with no custom installations of these elements. We were advised to take this action and push a new image to trigger a new scan. Since this doesn't appear to be the correct route, please advise us as to what we should be doing to use the most up to date images available from alpine. If no action needs to be taken here, we will close this PR. Thank you.

[yosifkit]

Are you talking about the following ones shown by the Docker Hub security scanning?

• pcre 8.41-r0: CVE-2017-11164

  • https://bugs.alpinelinux.org/issues/7702

  • We have had the compile option --with-match-limit-recursion=8192 since
    the very first commit so we have never been affected by this CVE.

• zlib 1.2.8: CVE-2016-9843, CVE-2016-9841, CVE-2016-9840, CVE-2016-9842

  • https://bugs.alpinelinux.org/issues/7356
  • tldr: fixed on 6 June (Alpine image was updated on 28 July and the Kong image was built on 13 September)

• perl 5.24.1-r2: CVE-2016-1238, CVE-2017-12883, CVE-2017-12837

  • no mention of any of these three in Alpine Linux bugs, so apk upgrade won't fix anything
  • does Kong use perl in a way that these would cause an issue? The only thing running in the container is Kong, so there is no other external attack vector.
  • in order to have a fix for these, there would need to be bugs filed with Alpine Linux

Maybe the pcre and zlib CVEs should be reported to Docker as false positive?

If a scan shows a vulnerability that you think is incorrect, if you think a vulnerability’s category is incorrect, or if you believe there is a vulnerability that has not been detected by the scanning process, contact Docker Support and include the information listed here.

scanning FAQ

[p0pr0ck5]

@yosifkit yes those are he packages we are referencing. There are no more recent versions of these packages, so we contacted docker support. They then told us to submit a new image. We indicated explicitly that PCRE and perl should be excluded because there are no newer versions here.

What I don't quite understand is why the scan reports zlib as version 1.2.8 when, if you do a docker pull of our current image and "apk info zlib", it shows a newer version. And we are not installing zlib manually in our docker file as you can see; zlib is provided by alpine image, and that version is latest (I believe 1.2.11). If the Kong image was built after alpine image was updated, why does the scan then show an old vulnerable version? Thank you for your time and helping clear this up. We are also in contact with docker support and will reference this conversation. Thank you again.

[ncopa]

@p0pr0ck5 What I don't quite understand is why the scan reports zlib as version 1.2.8 when, if you do a docker pull of our current image and "apk info zlib", it shows a newer version

Can you figure out which file it is that trigger the zlib CVE? I suspect it is not the zlib.apk.

We had a recent issue with python, where python ships some precompiled wininst*.exe files with the sources. Those are windows binaries which has a statically linked version of an old zlib which was triggered by the scanner. I suspect there are other binaries which is statically linked to old zlib.

I'll try fix the perl issues ASAP.

[ncopa]

• zlib 1.2.8: CVE-2016-9843, CVE-2016-9841, CVE-2016-9840, CVE-2016-9842

Apparently it is perl that bundles a vulnerable version of zlib. I'm gonna fix this too.

[ncopa]

the zlib 1.2.8 issue should be fixed with alpinelinux/aports@655e1b3

I think the false positive for pcre is about to be fixed too, so hopefully it will be all green tomorrow.

Thank you for your help solving those!

[p0pr0ck5]

@ncopa thank you! This is awesome to hear!

What do we need to do at this point moving forward? Do we need to push a new Docker image/create a PR here? If so, how do we do this if we don't have any changes to make with our own Dockerfile?

[yosifkit]

We heavily use docker caching for the official image builds, so anything added to the Dockerfile would be a bit of a hack to get it to rebuild starting at the right point. But it looks like there should be a rebuild of the base Alpine images next week (once gliderlabs/docker-alpine#337 gets finished). And once PR'd and merged in official images, will trigger in our build servers to rebuild all dependent images.

TL;DR: it should naturally work itself out once we get new Alpine image builds. Hopeful for next week.

[shashiranjan84]

As per above discussion, this PR is not needed.