When dealing with production container images, it's important to recognize that they aren't just simple combinations of a base image and the app. They often include custom layers, pinned packages, and specific quirks that make swapping out the base image impractical. With scanners flagging numerous CVEs (Common Vulnerabilities and Exposures), how can you effectively address these issues without compromising compatibility or necessitating a complete migration?
4 Answers
If you can't modify your base images to improve their security, that might be a risk on its own. It’s concerning if the people enforcing these as-is image builds don't grasp the essential rules of container security.
One way to deal with this is to focus on remediation in the base image itself. However, a challenge comes when CVEs are introduced by pinned packages or other app layers after the initial base image. Do you end up rebuilding the whole image every time, or is there a way to limit fixes just to the layers that have changed?
True, it's definitely tricky! We often find ourselves redoing the entire build, which feels inefficient. I wish there was a more streamlined approach to target only the necessary layers.
Has anyone looked into how rolling stable tags work with enterprise-managed base images? It would involve pulling images from upstream repositories, adding your own layers like enterprise CA certs, and ensuring everything is compliant and versioned properly. Do any of you follow this practice? Is it effective, or should we stick to using immutable tags and automate updates with something like Renovate bots?
The best strategy is to avoid getting into a situation where upgrades are a nightmare. Keeping images easily upgradable should be a top priority to manage security effectively. Trying to patch issues on newer layers may only complicate future upgrades. You may end up with no secure version of a needed dependency, forcing you to run insecure software. It's worth considering doing the heavy lifting required to ensure you can smoothly upgrade the base image whenever needed.
I totally get that. However, we're often held back by strict compatibility, change controls, and vendor restrictions on certain images. We're trying to minimize risk without triggering a full migration. Is there a way to find a balance here?