Docker: Switch base image to ubuntu:latest from debian:stretch to avoid security issues.

[bergquist]

Let's see what the CI pipeline say about it.

ref #14182

[bergquist]

Removed --fast so we build arm containers as well.

[xlson]

Looks good. I read a little about the release, trying to figure out when it's going from testing to stable (some time this year) and found this:

Please note that security updates for testing distribution are not yet managed by the security team. Hence, testing does not get security updates in a timely manner. You are encouraged to switch your sources.list entries from testing to stretch for the time being if you need security support.

source

Not sure how much this affects our decision.

[bergquist]

This makes total sense :)

The real workaround for this I guess is to rebuild old images, pull security updates from the mirrors and push them to dockerhub. It's not that strange that images we published 8 months ago have security vulnerabilities and fresh alpine does not. Switching from Debian to alpine or any other base would not help us regardless unless we republish old containers.

Alpine might have a smaller attack surface which is good. But we still need to republish those containers to get security fixes.

[xlson]

I could be wrong, but I think part of our problem is that there aren't security fixes for all the issues in stretch.

[woodsaj]

As @xlson points out, the security update issue isn't about updating existing installations. It is about there being a lag for security fixes showing up in the repo.

I guess the question comes down to: is buster more secure than stretch?

My opinion is yes. Right now, buster has fewer known vulnerabilities then stretch. Security updates for buster may not yet be managed by the security team, but they will when it becomes stable and so security should improve. For stretch, security updates are managed by the security team, but they still haven't fixed high severity issues that have be known for a really long time.

[xlson]

That's a good point. I agree, let's move to buster for now.

[bergquist]

TLDR; Phantomjs does not work on buster out of the box.

Copy pasting what @xlson wrote on slack

t=2019-05-16T07:51:01+0000 lvl=info msg=Rendering logger=rendering path="d-solo/ppGIbmWZz/new-dashboard-copy?orgId=1&from=1557971460841&to=1557993060841&panelId=2&width=1000&height=500&tz=Europe%2FStockholm"
t=2019-05-16T07:51:01+0000 lvl=dbug msg="executing Phantomjs" logger=rendering binPath=/usr/share/grafana/tools/phantomjs/phantomjs cmdArgs="[--ignore-ssl-errors=true --web-security=true --local-url-access=false --debug=true /usr/share/grafana/tools/phantomjs/render.js url=http://localhost:3000/d-solo/ppGIbmWZz/new-dashboard-copy?orgId=1&from=1557971460841&to=1557993060841&panelId=2&width=1000&height=500&tz=Europe%2FStockholm&render=1 width=1000 height=500 png=/var/lib/grafana/png/UWq6y0vo1U6tsYQEgUcC.png domain=localhost timeout=60 renderKey=BddXCMP6Ykv9tQJC4H6hvYa3JQAfCJI7]" timezone=Europe/Stockholm
t=2019-05-16T07:51:01+0000 lvl=dbug msg="Phantomjs output" logger=rendering out=
t=2019-05-16T07:51:01+0000 lvl=dbug msg="Phantomjs error" logger=rendering error="exit status 1"
t=2019-05-16T07:51:01+0000 lvl=eror msg="Phantomjs exited with non zero exit code" logger=rendering error="exit status 1"
t=2019-05-16T07:51:01+0000 lvl=eror msg="Rendering failed." logger=context userId=1 orgId=1 uname=admin error="exit status 1"

grafana@049524d5ecd4:/usr/share/grafana/tools/phantomjs$ ./phantomjs 
Auto configuration failed
140631040630400:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory
140631040630400:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
140631040630400:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=ssl_conf, path=ssl_conf
140631040630400:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=ssl_conf

bazelbuild/rules_closure#351

Leo: But it sounds like the newer openssl and phantomjs aren't compatible.

creating an empty file as /etc/ssl/openssl.conf as suggested in AustinSchuh/rules_closure@a932350#diff-c58da55f8955a22ae62287e8fea9ad7eR1 might solve it but I'm not sure that's a solution we want.

To build and package grafana as a docker container...

go run build.go build pkg-archive latest sha-dist && \
cp dist/grafana-latest.linux-*.tar.gz packaging/docker && \
./packaging/docker/build.sh --fast fakegitsha && \
docker run --net=host -e GF_LOG_LEVEL=debug grafana/grafana-dev:fakegitsha

[bergquist]

Phantomjs works fine on ubuntu:latest.

Results from running trivy locally

https://github.com/knqyf263/trivy/releases/download/v0.1.1/trivy_0.1.1_Linux-64bit.tar.g
tar zxvf trivy_0.1.1_Linux-64bit.tar.gz
make build-docker-dev
./trivy --exit-code 1 --quiet --auto-refresh --format=json grafana/grafana:dev

ubuntu:latest

CRITICAL        0 
HIGH            12 
MEDIUM	        33
LOW 		17

debian:stretch

CRITICAL	3
HIGH            38
MEDIUM          98
LOW		37

Since Ubuntu is based on debian I think it shouldn't cause any problems to switch base for the docker image.

[xlson]

Ubuntu seems like a good option if that gets us part of the way. How much bigger is the image vs the slim ones from debian?

[bergquist]

debian:stretch-slim is 22mb
ubuntu:latest is 29mb

So I dont think its an issue.

[bergquist]

I think this deserves a longer beta period than we normally do.