Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

banyanops.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#41

Post by jkyle »

I have a few contentions with the study.

First, if you look at their own analysis the number drops from 30% to 23% when limited to only the latest tagged images in the official repository. I'd expect to see a higher rate of vulnerabilities in previous versions...that's why you rebuild. Find me a linux admin that would accept their OS is vulnerable if you're citing old, unpatched versions.

Second, they seem to virtually _all_ be package vulnerabilities. These would, ostensibly, reach parity with whatever the target distro is by simply updating packages on a rebuild.

Finally, I think one would be hard pressed to lay any vulnerabilities traced to updated, current packages at the feet of docker. That fault would seem to lie squarely with distro package maintainers.

So, two simple rules would seem to bring the security of container deployment in line with standard bare metal deployment (by the metrics applied in this research):

1. Don't use old shit

2. Rebuild your selected docker container to ensure packages are up to date. Why? See rule #1.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#42

Post by pyre »

dredmorbius wrote: post #40
pyre wrote: post #38

Earlier quoted context omitted.

> Bundling dependencies for production environments has always been and always will be a terrible idea. If you are not bundling dependencies how do you rollback a deploy that migrated to a new version of a dependency? If you rollback your code, you also have to do something to rollback the dependency. For Python, I currently rebuild a virtualenv from scratch on each deploy, but it just feels like a poor solution. Doc…

If you're basing deploys on image builds, you're not "rolling back" anything, but are building a new host (or host image) based on the correct dependencies. That process relies on your platform's own dependency-resolution system, and I hope you're using something sane such as Debian/Ubuntu, or are building from source via Gentoo. RPM distros can work but tend to be far flakier. Start with a base install, have a packa…

I think that the "real" problem here is that Python's package management and apt/yum don't really interface well. I've built .debs for Python packages before, and it was a huge pain in the ass, even with the scripts and automations that I was able to find for it.

It's 'simple' for me to build a virtualenv in a directory with `pip install -r requirements.txt` in my source repo, but everything I've read about making those virtualenvs portable (even moving them between directories on the same server you built them on) is that it is a path fraught with peril.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#43

Post by pyre »

ilogik wrote: post #39
pyre wrote: post #38

Earlier quoted context omitted.

> Bundling dependencies for production environments has always been and always will be a terrible idea. If you are not bundling dependencies how do you rollback a deploy that migrated to a new version of a dependency? If you rollback your code, you also have to do something to rollback the dependency. For Python, I currently rebuild a virtualenv from scratch on each deploy, but it just feels like a poor solution. Doc…

I think you can with the latest version of Pip (7) https://lincolnloop.com/blog/fast-immutable-python-deploymen...

He's talking about exactly what I am currently doing:

> It's now feasible to build a new virtualenv on every deploy. The virtualenv can be considered immutable. That is, once it is created, it will never be modified. No more concerns about legacy cruft causing issues with the build.

> This also opens the door to saving previous builds for quick rollbacks in the event of a bad deploy. Rolling back could be as simple as moving a symlink and reloading the Python services.

This is exactly what I do now: a new virtualenv from scratch on each deploy in the same directory with all other build artifacts (so that each deploy is in a self-contained, timestamped directory that is swapped out with a 'current' symlink). I just bite the bullet on the additional time it takes to deploy.

The part of this blog post that affects me is that upgrading to pip 7 would speed up my deploy times.

This part seems interesting:

> Another possibility is building your wheels in a central location prior to deployment. As long as your build server (or container) matches the OS and architecture of the application servers, you can build the wheels once and distribute them as a tarball (see Armin Ronacher's platter project) or using your own PyPI server. In this scenario, you are guaranteed the packages are an exact match across all your servers. You can also avoid installing build tools and development headers on all your servers because the wheels are pre-compiled.

I've looked at platter a bit, but I haven't really digested what will be needed to migrate to that point, and he doesn't really expand on it.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#44

Post by bkeroack »

They should do the same study for VM images on Vagrant Cloud (aka Hashicorp Atlas), or any other repository of binary software/images built by untrusted third parties.

I thought it was obvious that public images on Docker Hub were to be used for experimentation only--even in that case I only use the "official" Docker images in the library namespace. Anyone using Docker for serious purposes should build their own or at least vet the pre-built images.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#45

Post by [deleted] »

jkyle wrote: post #41

I have a few contentions with the study. First, if you look at their own analysis the number drops from 30% to 23% when limited to only the latest tagged images in the official repository. I'd expect to see a higher rate of vulnerabilities in previous versions...that's why you rebuild. Find me a linux admin that would accept their OS is vulnerable if you're citing old, unpatched versions. Second, they seem to virtual…

[deleted]

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#46

Post by s_baby »

jeromenerf wrote: post #29
s_baby wrote: post #23

Earlier quoted context omitted.

That's why you keep everything with state in a separate volume container. Attach volume to built image and that's it.

Mount data, logs, configuration, eventual extensions in the data container? For pg, there might be some migration needed when jumping from a major version to the next. Which requires both versions installed, on Debian at least.

>Mount data, logs, configuration, eventual extensions in the data container?

Many programs have their state represented as files that are stable across versions. If you have a cluster of the same image with different states it's more efficient to move volume containers across a network. Easier to backup/upgrade too.

pg is going to give you those problems whether you are using Docker or not.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#47

Post by Sleaker »

jkyle wrote: post #41

I have a few contentions with the study. First, if you look at their own analysis the number drops from 30% to 23% when limited to only the latest tagged images in the official repository. I'd expect to see a higher rate of vulnerabilities in previous versions...that's why you rebuild. Find me a linux admin that would accept their OS is vulnerable if you're citing old, unpatched versions. Second, they seem to virtual…

I thought the point of using docker containers was that they were pre-packaged apps. Not so you had to continually rebuild the container with your own updated packages. Doesn't having to rebuild the container to fix security vulns defeat one of the major reasons to have versioned docker images released for use? You could very well end up breaking dependencies.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#48

Post by DannoHung »

Sleaker wrote: post #47
jkyle wrote: post #41

I have a few contentions with the study. First, if you look at their own analysis the number drops from 30% to 23% when limited to only the latest tagged images in the official repository. I'd expect to see a higher rate of vulnerabilities in previous versions...that's why you rebuild. Find me a linux admin that would accept their OS is vulnerable if you're citing old, unpatched versions. Second, they seem to virtual…

I thought the point of using docker containers was that they were pre-packaged apps. Not so you had to continually rebuild the container with your own updated packages. Doesn't having to rebuild the container to fix security vulns defeat one of the major reasons to have versioned docker images released for use? You could very well end up breaking dependencies.

You're sort of combining two things: 1) Docker makes it super simple for anyone to package software and run it 2) Dockerhub makes it simple to share software that you have packaged with other people.

Personally, my biggest gripe with Dockerhub is that a Dockerfile should be required in order to upload to the hub, and it should show the Dockerfile that produced each version. The fact that people can create fundamentally unreproducible binaries is nasty (there's also the issue of not specifying versions in the apt/yum steps used in the Dockerfiles, but that's just a general problem with the way package management software is designed).

None of that's a problem with Docker itself though.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#49

Post by angersock »

vidarh wrote: post #26
eliaspro wrote: post #2

Not surprised at all. And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance. Bundling dependencies for production environments has always been and always will be a terrible idea.

Do you believe that locally built "homegrown" deploys on average are going to be better or worse than these images? Because I know what I'd bet on.

Homegrown every time, sadly.

EDIT:

Reason being, you can more easily deal with silly things like goofy hosts, goofy networks, possible lack of internet connections, bad host OS support, etc.

The normal downsides of doing it yourself of course apply.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#50

Post by evol262 »

jkyle wrote: post #41

I have a few contentions with the study. First, if you look at their own analysis the number drops from 30% to 23% when limited to only the latest tagged images in the official repository. I'd expect to see a higher rate of vulnerabilities in previous versions...that's why you rebuild. Find me a linux admin that would accept their OS is vulnerable if you're citing old, unpatched versions. Second, they seem to virtual…

My primary contention with your post is that docker doesn't provide a package-manager-like way of ifnding out whether or not you're running older images. Everyone has their own homegrown way of doing it.

1. Don't use old shit 2. Docker should provide a way to tell you you're not running the latest tagged image so you stop running old shit 3. Don't use base images whose maintainers can't be bothered to rebuild when security updates hit

Post reply on HN