5 ms·
It isn't an unsolvable problem but I predict that in many organizations, containers will mean more instances of critical hot-fixes (to library components outsid
by jeremyjh 9y ago
It isn't an unsolvable problem but I predict that in many organizations, containers will mean more instances of critical hot-fixes (to library components outside the kernel - e.g. openssl) not being applied across the board because the development teams manage the container image and once the product is in maintenance no one is going to be updating them. This is mitigated by a smaller attack surface but its still a concern.
- nova22033 9y ago>once the product is in maintenance no one is going to be updating them. That's not a container specific problem. That happens even when you don't use containers.
- sedachv 9y agoThere is a lot of misleading marketing hype, misunderstanding, and plain misinformation about how containers/Docker make updates, and in particular security updates, easier, when the opposite is the reality. A lot of people buy into the CoreOS marketing hype, as though it was the only Linux distribution to offer automatic security updates. If you use containers as recommended, in fact the only thing CoreOS gives you are kernel updates, which is less than what other distributions provide. To get userland updates with Docker, you have to update your base image, then rebuild and re-deploy your application image, for every single application that you have. Or use custom kludge layers for updates: https://github.com/SUSE/zypper-docker https://github.com/SUSE/zypper-docker https://github.com/projectatomic/rpm-ostree https://github.com/projectatomic/rpm-ostree Making maintenance and updates harder is definitely a container specific problem.
- jeremyjh 9y agoMany organizations have operations teams that are responsible for ensuring servers get patched on a regular schedule, and there is an entire industry of software to confirm whether or not they are doing it properly. But I know for a fact that at some of these same organizations, the deployable unit is a Docker image that the development team pushes to the repository when it suits them. Operations doesn't have the ability to patch the software in the container, and the auditing tools haven't caught up either.
- deleted 9y ago[deleted]
- yokohummer7 9y agoWhen I learned Docker for the first time I was so surprised that so few people mention the problem. As one who is used to automatic secutity updates provided by Linux distributions, relying on manual `docker build`s gives me anxiety. I use Docker because it solves many of my problems, but I have not been able to feel easy from potential security concerns from the beginning.
- hibbelig 9y agoI used to think like that as well. But what is “manual” about “docker build” that isn’t also manual with “apt full-upgrade”, say?
- gruez 9y agoyou can configure unattended-updates with apt-get. I guess you can do the same with docker if you use some sort of CI service + auto deploy script, but it's way more work + way more opportunities for failure
- yokohummer7 9y agoWhat I meant by "automatic" was Ubuntu/Debian's unattended upgrade feature. I've used it for years without any problem, and it has relieved much of my maintenance burden. Maybe I need to enable it in containers too? I have no idea how to use it on (containerized) Alpine Linux though. Even without unattended upgrades, finding the list of `Dockerfile`s and `docker-compose.xml`s that might be affected by a new vulnerability sounds more complicated to me. Until now it hasn't been that difficult but I'm still a bit nervous if I somehow missed some vulnerable images.