Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities • Hacker News Board

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

#51

Post by Sleaker » Wed, May 27, 2015, 4:48 PM UTC

DannoHung wrote: post #48

Sleaker wrote: post #47

Earlier quoted context omitted.

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 fundamental…

Ahh got it. I have only really used lxc, so not super familiar with docker other than it being a container tech. Thanks for the explanation :D

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

#52

Post by efuquen » Wed, May 27, 2015, 4:55 PM UTC

evol262 wrote: post #50

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 se…

Does AWS does this with their AMIs? Everything you listed can be applied in virtually the same way with VM images, and their are community based AMIs with all sorts of vulnerabilities and non-updated code, people just know not to use them or build their own.

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

#53

Post by DannoHung » Wed, May 27, 2015, 4:56 PM UTC

KaiserPro wrote: post #22

justingood wrote: post #6

Earlier quoted context omitted.

"The technology of deployment does not change 'minutes or hours' into 'days or months'" I wouldn't say that's true. We're transitioning into multiple languages, and want to have an environment that will allow future languages to be added as required. Building a generic infrastructure to run containers lets us run everything on the same base platform. Otherwise, we'd need to tailor the images and configuration for the…

Or, you could do what HPC has been doing for years and seperate the config from the machine. What do I mean by that? shared drives. Seriously, install python$ver plus dependenceies into /mnt/bin add it into your path. You now have a single source of (readonly optional) each binary version. this means that you can have many versions of the same software all compiled in a different way. But because they are in the path…

We do this at my company and it is a fucking nightmare. Why? Because there are like 4 different operating environments and there isn't an official way to do installations and you also have to manage site installations of various packages for each version of each language dependency. And god forbid some environment variable is pointing to the wrong version of something because it's not just as simple as setting PATH and LD_LIBRARY_PATH when every thing and its mother tries to set its own fucking environment variables all pointing to wherever they think they were compiled at.

No, it is much much MUCH better to actually have an application build with its dependencies and deploy with its dependencies. And you know how you fix issues with security patches? You have a real build system that rebuilds your binaries and you redeploy regularly.

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

#54

Post by efuquen » Wed, May 27, 2015, 4:59 PM UTC

I wonder what would happen if you attempted the same study with AWS AMI's on the official images. Get the latest versions, don't update your distro, and see how many vulnerabilities you get. How often does AWS really rebuild their official AMIs?

Ultimately keeping your OS completely up to date is on you, not Docker, not Amazon, you. VM's suffer from the exact same problems as Docker containers.

Edit: Also, security issues with using community AMIs are already well known, should be no surprise the same applies to Docker community images.

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

#55

Post by evol262 » Wed, May 27, 2015, 5:04 PM UTC

efuquen wrote: post #52

evol262 wrote: post #50

Earlier quoted context omitted.

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 se…

Does AWS does this with their AMIs? Everything you listed can be applied in virtually the same way with VM images, and their are community based AMIs with all sorts of vulnerabilities and non-updated code, people just know not to use them or build their own.

Well, no. Everything I listed can be applied in virtually the same way to openstack images or AMIs or whatever... except that the intended use case of those includes regularly updating packages, which docker does not.

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

#56

Post by innguest » Wed, May 27, 2015, 5:14 PM UTC

jakozaur wrote: post #4

A bit overstated. They definition of security vulnerable == got package which is vulnerable. However, merely having some packages with vulnerabilities may not be enough. E.g. you have security in package manager (apt), but you never use it after building the image. Or even shellshock is no flyer, if you don't use CGI scripts and don't have ssh access. In Virtual Machines this problem also exists. I guess it is more a…

Tell me about it!

Gotta love those security experts that your company hires when they say to you "your app has a security issue right here" and I say "alright then prove it, hack it, let's see if there really is a security issue" and they can't do it.

If I don't want to worry about deployment, there's Heroku. If I don't want to worry about testing, there's Circle CI. If I don't want to worry about scaling, there's AWS EC2. If I don't want to worry about security, there's... nothing. Because it's not a real product. At least not real in the way databases, deployment, testing and scaling are.

So when people say "programmers don't care about security" I honestly don't understand what they mean since I've never seen a secure app. It's like there's this mob of believers that want to convince you security is the salvation. OK, teach me by showing. Show me a bunch of secure apps and we'll learn from it. But those don't exist, so no one ever learns, but that doesn't keep "security experts" from blaming programmers building real things in the real world for not caring about their imaginary friend.

I'll believe security experts care when they create a service and sell it for money to people like me.

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

#57

Post by thomasvendetta » Wed, May 27, 2015, 5:46 PM UTC

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…

So if you rebuild your docker containers every time you deploy, and you deploy daily, security updates should happen on a daily basis. Correct?

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

#58

Post by jkyle » Wed, May 27, 2015, 6:01 PM UTC

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.

I would say the primary benefit of docker is that you can build once, run the same everywhere.

E.g. you have a consistent, reproducible application environment which _should_ be vetted through a gauntlet of continuous integration, testing, etc. that once created will run identically on any host running docker.

If you have a "trusted source" to do all the grunt work for you, fine. But docker's promise isn't guaranteeing a trusted source. It's providing a consistent, invariant application target from developer laptop -> production host.

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

#59

Post by jkyle » Wed, May 27, 2015, 6:03 PM UTC

thomasvendetta wrote: post #57

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…

So if you rebuild your docker containers every time you deploy, and you deploy daily, security updates should happen on a daily basis. Correct?

Correct!

And if you have a continuous integration environment building and validating artifacts on every developer commit with a regular, vetted release cycle that catches any regression bugs...

Well, now you're on the right track.

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

#60

Post by jkyle » Wed, May 27, 2015, 6:06 PM UTC

evol262 wrote: post #50

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 se…

Well, all docker containers are hashed and can be version tagged. If you do a pull and run the 'latest' tag, it'll always be the HEAD of the commit hash.

This is assuming you want to trust some 3rd party with the maintenance and security of your production environment.

Docker containers are, usually, just operating systems running a single logical application service. I don't think Docker promises a free Sys Admin. ;)