4 ms·

Don't you think that gitlab adding container registry support will encourage more people to build their own images, as opposed to trusting "black-box" images fr

by moondev 10y ago

Don't you think that gitlab adding container registry support will encourage more people to build their own images, as opposed to trusting "black-box" images from elsewhere? Combining a base image with the deployable artifact is much more efficient than baking amis or other images. You then know exactly what your image contains and nothing more, because you built it yourself. Of course I'm looking at this from the perspective of deploying micro-services and immutable infrastructure. Your use-case may be different.

davexunit 10y ago
Any nontrivial image relies on a large number of other images as a base, and just because you built it yourself doesn't mean that you didn't just download and install software with known security vulnerabilities.
- snuxoll 10y ago
  Yes, but you will ALWAYS have that issue with software you build yourself. This is primarily why I maintain an in-house yum repository for anything that we use out of our distribution repositories, it takes a little more effort to build RPM's but it's worth it from a maintainability and security aspect (as I type this I'm working on a salt-based package management tool somewhat akin to Katello/Sattelite that I can use to manage upgrades that Puppet doesn't).
- moondev 10y ago
  The thought is you use a vanilla LTS image as a base. If that needs to updated then your ci can easily do it. You then combine that with your installable artifact (deb, rpm). It's the same exact process using classic images, so i'm not sure what the complaint about docker specifically would be.
- voltagex_ 10y ago
  At least by building images by myself I'm taking responsibility in a way for the security of them - rather than relying on the (in)security of whatever base image. I did see a feature somewhere for scanning container images for security vulnerabilities, but I think something closer to FreeBSD's pkg-audit is needed.
sytse 10y ago
I agree that building your own images is the future. We want to make this as easy as possible. I think it is essential for security.

by moondev 10y ago

davexunit 10y ago

Any nontrivial image relies on a large number of other images as a base, and just because you built it yourself doesn't mean that you didn't just download and install software with known security vulnerabilities.

snuxoll 10y ago
Yes, but you will ALWAYS have that issue with software you build yourself. This is primarily why I maintain an in-house yum repository for anything that we use out of our distribution repositories, it takes a little more effort to build RPM's but it's worth it from a maintainability and security aspect (as I type this I'm working on a salt-based package management tool somewhat akin to Katello/Sattelite that I can use to manage upgrades that Puppet doesn't).
moondev 10y ago
The thought is you use a vanilla LTS image as a base. If that needs to updated then your ci can easily do it. You then combine that with your installable artifact (deb, rpm). It's the same exact process using classic images, so i'm not sure what the complaint about docker specifically would be.
voltagex_ 10y ago
At least by building images by myself I'm taking responsibility in a way for the security of them - rather than relying on the (in)security of whatever base image. I did see a feature somewhere for scanning container images for security vulnerabilities, but I think something closer to FreeBSD's pkg-audit is needed.

sytse 10y ago

I agree that building your own images is the future. We want to make this as easy as possible. I think it is essential for security.