i use Rancher now in production and it does a great job. I was always concerned about the security of the docker images. Thats way i use Clair (https://github.com/coreos/clair) to ensure my applications run with no vulnerabilities.
But if i scan the Rancher images is see a lot of problems ( i attached 2 examples reports)
Does anybody know why this is the case and if its expected that we reach a “better” level here?
The only “right” answer here is that we can do a better job of updating, which I will bring up. But the practicality is that updating everything constantly adds considerable risk and testing for what is usually no benefit other than passing scanner reports like this.
If you really read through the list, few if any at all are actually relevant. There’s libraries and binaries that come with the base Ubuntu image, but haproxy does not use them (e.g. libxml2) directly, and it is the only thing exposing an interface to the outside world. If you’re inside the container then you already have full access and an exploit of curl, wget, bash, vim, etc isn’t going to gain you anything.
Just to say even a fully patched ubuntu:1604 got security issues ( i think 12 - 22) . I totally understand your point.
I created reports for all rancher images running at my cluster.
Actually what is important for me is can we rely on Rancher that they take care about the security especially for services facing to the public.
Example:
I am running Rancher version 1.5.9 with HAProxy now a critical security issue was found and patched by HAProxy. How fast can Rancher user get notified and have a updated HAProxy Image? (how will / is that handled / Security mailing list?)
FYI:
I just want to make clear that i really like the way Rancher / you treat the community and this is no finger pointing
You can subscribe to the Announcements forum here to get notifications of releases. Specific ones for a security issue will be labeled as such (which happened once, fairly recently). If it’s in a microservice outside the main image then a new image would be pushed and the catalog updated, which will show “upgrade available” in the UI. There is also an auto-upgrade option in 1.6 that can be enabled (though it is only for system services, and the balancer isn’t one…)
So maybe using the smallest base images helps - not Ubuntu but Debian or Alpine, so there will not be outdated and not used packages. Also more faster deployment is benefit.