Hacker News Reader

Comment by theamk | Hacker News Reader

The big question about using those Docker containers is security.

Based on past CVE history for nginx, there might be another CVE in 1-2 years. Will this git repo still be updated then? Will the user remember to pull latest version and regenerate latest image?

Official "nginx:alpine" image maintained by nginx team is 17MB. If you can, you should always use it. And you should subscribe to some sort of mailing list so you know when it is time to upgrade all of your servers.

(An alternative is to skip docker and use good old Ubuntu LTS with automatic updates; this will guarantee timely and fully automatic security updates for the next few years. The downside is that if the system will have an exploit, the attacker will often find it much easier to stay in the system and move to other parts of the network)

View on HN

> Will this git repo still be updated then? Will the user remember to pull latest version and regenerate latest image?

I use this image myself, so I have an incentive to keep it up-to-date and secure.

Usually, I upgrade in less than 24h from the release of a new patch. Based on the system I use to get notified of upgrades such as NGINX's, I could even automate the upgrades to get triggered as soon as the patch is released, but I don't like the idea of commiting without human review.

But I see your point. There's no guarantees. What happens if I get tired (highly doubt so), or, what happens if I die? These problem is inherent with open source software maintained by volunteers.

I tried pushing my changes to the official NGINX image, but they can't be merged because I'm using multi-stage builds, which for some reason are not allowed for official images. Here's the PR: https://github.com/nginxinc/docker-nginx/pull/310 Multi-stage builds is the core of what makes this image great, so I can't renounce to it.

I think we can also agree that, because Docker is very new, we cannot guarantee that it's as secure as other well-tested technologies, but if Docker/Kubernetes were to be secure, it let's admins take security to another level. You could have 2 stacks, with all their components, running on the same metal, but isolated at the network level. Doing this is possible without containers, sure, but it takes less than 5 lines of YAML in Docker Swarm.

Exciting time in the world right now. Exciting time...

Agree, security here is a bold claim. Size does not imply security. Traceability, reproducibility, maintenance/rate of release, etc are... I'd rather use official images as they are maintained and reported against (or reported to the maintainer) when issues are found.

OP and maintainer of the image here.

I understand your concerns. I would have them too.

To be fair, I tried pushing these changes to the official NGINX image, but they weren't accepted because I'm using a multi-stage build, which are not allowed to official images for a series of reasons. I mostly disagree with those reasons, but I don't own the Docker Hub. Here's the PR: https://github.com/nginxinc/docker-nginx/pull/310

As for traceability, we've had some discussion over at Lobsters about that. I believe you can do it from outside the container, and avoid bloat that will only get used in 1% of the cases.

About reproducibility, my CI process for this image uses GitHub and the Docker Hub, I don't build and push the images myself (which I consider a very big red flag in A LOT of images, even official ones), so it must be reproducible as the Docker Hub must be able to build it.

I've responded to another user about maintenance. TL;DR is: I use it, so I must keep it up-to-date, usually in less than 24h of the release of a new patch. If for whatever reason I stop using it, upgrading is just changing two lines in the Dockerfiles, so it's not tiring. But if for whatever reason I can't maintain it anymore... This is an inherent problem of volunteer maintained open source software.

I might have convinced you, or not. Again, I'd have the same concerns as you do, it's fair.

Reply on news.ycombinator.com