We're in the process of scaling our containerized applications and we've recognized the need to standardize on base images for security and compliance. However, we're facing challenges since each team seems to have their own preferences when it comes to image selection. Policy as code feels overly complicated to implement, and blocking pull requests seems to slow down our progress significantly.
I'm curious to hear what strategies others have employed to work through this issue. Is it effective to use automated scanning that flags images not on an approved list but allows deployments to continue initially? Or would running image registries that only permit approved pulls be better?
Any recommendations for tools or workflows that facilitate a gradual rollout of these changes? I'm eager to avoid creating a situation where we disrupt everyone's ability to deploy.
2 Answers
One approach is to invest in high-quality base images that are user-friendly. For instance, we've had success with Chainguard, even though it's on the pricier side. It's also crucial to get leadership involved and set a compliance deadline—say six months. After that, all non-compliant applications should be pulled into a dedicated incident bridge call until they resolve the issues.
I think you might be overthinking it a bit! Instead of easing into it, just go ahead and enforce approved base images using the Kyverno admission controller right at deploy time. Teams usually adapt pretty quickly when their builds start failing consistently. We’ve switched to using Minimus for our base images along with Kyverno, which has made the rollout really smooth. Sure, some developers might be upset at first, but this way you'll have everyone using the same standardized images before long.
That sounds nice in theory, but enforcing rules like that can lead to teams finding workarounds instead of following the guidelines. It's all about having the right policy and tooling in place, but enforcing it can feel unrealistic sometimes.