Smaller images helps in two ways: 1 ) Minimized attack surface for possible vulnerabilities. 2) Easier for container orchestration (like k8s) to move such images around nodes, and pull them from registry. It thus affects the network traffic along with storage. Thus Alpine or anybase should be chosen keeping these in view.
Attack surface is important in security, so yes a smaller image is important, especially since we’re talking a order of magnitude here. It uses musl libc as a c library which aims to be correct. Bugs (and cruft) = security vulnerabilities.
I think size does matter as that generally implies a lot more lines of code and a greater risk for CVE's and even a greater risk for zerodays. Even though alpine doesn't allow for CVE scanning, I think you are overlooking the fact that less space in general should mean it's much easier to maintain by developers and therefor being more secure. Alpine may walk behind on CVE scanning, but 8GB vs 100MB should be a cause of concern. I do steer away from distro's with too many pre-installed items as that just seems to be asking for trouble. Finally we shouldn't be too worried about CVE's as they are known vulnerabilities which are generally patched up in the next update, we should be more worried about the potential for zerodays that a OS carries.
Very interesting arguments here! Although I disagree on the point at 14:25 that if you are already dealing with large images you probably don't care of space saving. An example: using ECS and Fargate, being thoughtful of the image size can save you a lot of time on deployments since images are transferred in full every time, it seems.
Any comments on the relevancy of this video , in 2022 . Are the container images scanners available in the market , still not able to scan Alpine images today , or has things improved ?
Because Alpine has so few packages included, wouldn't it be easy/easier to collect security information on the included packages and basically INFER how secure it is? It logically seems that an image 10x times larger would logically be less secure.
DIY > Performance > Security ("Safety Third" -Mike Rowe) *slaps OP with rolled up man pages* Respect earned by the Founders, "Show me the code!" - Linus Torvalds. You have done well to earn my eternal downvote i.imgur.com/8ubsP9s.gif
Smaller images helps in two ways:
1 ) Minimized attack surface for possible vulnerabilities.
2) Easier for container orchestration (like k8s) to move such images around nodes, and pull them from registry. It thus affects the network traffic along with storage.
Thus Alpine or anybase should be chosen keeping these in view.
I appreciate your videos, and your udemy courses. The topics you covered here are ones I'm been thinking about for a while, still in 2021!
Attack surface is important in security, so yes a smaller image is important, especially since we’re talking a order of magnitude here. It uses musl libc as a c library which aims to be correct. Bugs (and cruft) = security vulnerabilities.
that's my take away. I was lost with the argument on disk space.
Thanks for posting a pragmatic exploration on the topic. Good video!
I think size does matter as that generally implies a lot more lines of code and a greater risk for CVE's and even a greater risk for zerodays. Even though alpine doesn't allow for CVE scanning, I think you are overlooking the fact that less space in general should mean it's much easier to maintain by developers and therefor being more secure. Alpine may walk behind on CVE scanning, but 8GB vs 100MB should be a cause of concern. I do steer away from distro's with too many pre-installed items as that just seems to be asking for trouble. Finally we shouldn't be too worried about CVE's as they are known vulnerabilities which are generally patched up in the next update, we should be more worried about the potential for zerodays that a OS carries.
Very interesting arguments here!
Although I disagree on the point at 14:25 that if you are already dealing with large images you probably don't care of space saving. An example: using ECS and Fargate, being thoughtful of the image size can save you a lot of time on deployments since images are transferred in full every time, it seems.
Thanks, helped clear some things up for me!
Did not know about the scanner problem. All my projects use Alpine so I'm hoping the scanner issue has been fixed by now xD
Thanks for that! I knew It'd make sense to do my images in Arch :P
Any comments on the relevancy of this video , in 2022 .
Are the container images scanners available in the market , still not able to scan Alpine images today , or has things improved ?
You can go and check Apline project to see whether they are publishing the CVEs. :)
Good arguments and good explanation, thank you a lot for that.!!
Because Alpine has so few packages included, wouldn't it be easy/easier to collect security information on the included packages and basically INFER how secure it is? It logically seems that an image 10x times larger would logically be less secure.
Just a question to clear my doubts, doesn't the image size affect the memory usage by a docker container?
No it doesn't. Image size affects how much drive space is used. The app inside the container will decide how much memory (RAM) it needs.
Hey, you look like that guy who used to do “This Week In Linux”, back in the day.
DIY > Performance > Security ("Safety Third" -Mike Rowe) *slaps OP with rolled up man pages*
Respect earned by the Founders, "Show me the code!" - Linus Torvalds. You have done well to earn my eternal downvote i.imgur.com/8ubsP9s.gif