As those are built on Wolfi by Chainguard I would not use them in production. They restricted already their own images for only paid customers and also recently limited OSS entirely on Wolfi. So there is no guarantee how long the packages may be available for non paying customers.
Dumb question but how would these work in practice? I use kamal to deploy containerized applications. Would I on a regular basis update the versions of the underlying images to match the latest hardened container and then redeploy? I assume this is automatable?
Hi thanks for looking - I would preferably more info on your setup, but this is similar to using any container image. Currently all the tags are latest and if you have that setup you would pick that up from this repo and pretty sure this can be automated.
This is great. I have been talking to quite some vendors in the space. I have looked in docker hardened images too. They have made it free too.
I think the problem in general is hardened image market is keeping up with CVEs and making sure the catalog is vast so that it covers all the images and nuances.
Responding and patchibg CVEs with an SLA is the KPI of the vendors. As much as I would like cheer for you, doing it as an opensource initiate with a guaranteed SLA is going to be painful for you as maintainer without profit as a motive.
Thanks for looking into this! I agree with you and hence I'm also relying on Wolfi packages, which will ensure they are updated as soon as upstream is available so I'm piggy backing on that. Github Actions run daily/weekly based on the cadence and once the pipeline is setup do not require a significant effort imo. And I want it to be community driven so we can add images as and when people want it and build it accordingly. Chainguard tools surely help with this! I aim to show that companies can try and build internal pipelines like this for all images in their repository
Isn't this mostly the same thing that Chainguard already provides themselves? E.g. the "Free" images on their page [0] have a big overlap with the toolchains from your repo.
Some images do overlap yes, but they are some of the most popular ones used and I wanted to demonstrate how they can be build as well. Half of them are only available through paid versions. I will be adding new images on regular basis, based on usage and impact.
Ah, nice! I also just tried to look up how the official Chainguard images are built, and while the are open source they are less straightforward to follow.
I was looking into how to create more secure container image and this looks like a great resource! :)
> Some images do overlap yes, but they are some of the most popular ones used and I wanted to demonstrate how they can be build as well. Half of them are only available through paid versions. I will be adding new images on regular basis, based on usage and impact.
This looks really good. Good luck for your project!
Also a quick question but when you mention Minimal being well.. Minimal? How much more minimal would it be compared to say alpine?
Also maybe I should stop saying so many times minimal in this comment haha!
I think it depends on your use case, an image can be as small as default static, but if you need more, we need to add packages. Minimal images make sure we do that with least attack surface.
I have been curious on secure base images for the AI ecosystem, where we need to ship with cuda 11.8/12.8/13.1 for stability reasons, and in our case, a bit of the torch ecosystem and Nvidia rapids ecosystem. That ends up being... A lot. Extra fun: going all the way to FIPS..
I am pushing myself to learn nix and get rid of base images altogether.
The syntax is hard without a functional background but I strongly believe this is the next logical step to harden containers and have reproducible builds.
I'm not sure what problem this is solving. This seems like chainguard but being built in "your ci" (github) vs "their ci". Images may be a bit smaller, but this is already a feature set that wolfi already allows for. Besides that chainguard is not full-source bootstrapped.
Why does this not use chisel? I assume you at least drop the bin dir? Although the presence of ncurses is super weird
I don't understand why one would go halfway and leave packages which are unneeded for services. The only executable in a hardened container image should be your application.
Thanks! but these are builder images, not the final runtime. Chisel only really makes sense after the binary is built and you know what it needs at runtime. Before that you are pulling in whole packages, which is why things like ncurses might show up, similar to chainguard's image. For a builder, it is just SBOM noise and not something the app ever executes. Its hard to identify what you need before running the application, and you can always find a library you don't need.
The “only your app should be executable” idea works for fully static binaries, but once you use glibc or CGO you already have other executables.
Best to look at security policy using ecological predator-prey models. If you don't, than you fall victim to the assumption a "puzzle" you can't break is unbreakable in general.
Nuisance users don't publish CVE, and a zero trust model shows you something important. =3
Joel a little offtopic but looks like we have bumped into each other 3 times now (I remember you from VM comment and then today on a different comment and now this)
I am curious to ask now but why do you end every message with =3 & when did you start with this trend, really curious now xD
As those are built on Wolfi by Chainguard I would not use them in production. They restricted already their own images for only paid customers and also recently limited OSS entirely on Wolfi. So there is no guarantee how long the packages may be available for non paying customers.
Dumb question but how would these work in practice? I use kamal to deploy containerized applications. Would I on a regular basis update the versions of the underlying images to match the latest hardened container and then redeploy? I assume this is automatable?
Hi thanks for looking - I would preferably more info on your setup, but this is similar to using any container image. Currently all the tags are latest and if you have that setup you would pick that up from this repo and pretty sure this can be automated.
This is great. I have been talking to quite some vendors in the space. I have looked in docker hardened images too. They have made it free too.
I think the problem in general is hardened image market is keeping up with CVEs and making sure the catalog is vast so that it covers all the images and nuances.
Responding and patchibg CVEs with an SLA is the KPI of the vendors. As much as I would like cheer for you, doing it as an opensource initiate with a guaranteed SLA is going to be painful for you as maintainer without profit as a motive.
Thanks for looking into this! I agree with you and hence I'm also relying on Wolfi packages, which will ensure they are updated as soon as upstream is available so I'm piggy backing on that. Github Actions run daily/weekly based on the cadence and once the pipeline is setup do not require a significant effort imo. And I want it to be community driven so we can add images as and when people want it and build it accordingly. Chainguard tools surely help with this! I aim to show that companies can try and build internal pipelines like this for all images in their repository
Isn't this mostly the same thing that Chainguard already provides themselves? E.g. the "Free" images on their page [0] have a big overlap with the toolchains from your repo.
[0]: https://images.chainguard.dev
Some images do overlap yes, but they are some of the most popular ones used and I wanted to demonstrate how they can be build as well. Half of them are only available through paid versions. I will be adding new images on regular basis, based on usage and impact.
Ah, nice! I also just tried to look up how the official Chainguard images are built, and while the are open source they are less straightforward to follow.
I was looking into how to create more secure container image and this looks like a great resource! :)
> Some images do overlap yes, but they are some of the most popular ones used and I wanted to demonstrate how they can be build as well. Half of them are only available through paid versions. I will be adding new images on regular basis, based on usage and impact.
This looks really good. Good luck for your project!
Also a quick question but when you mention Minimal being well.. Minimal? How much more minimal would it be compared to say alpine?
Also maybe I should stop saying so many times minimal in this comment haha!
I think it depends on your use case, an image can be as small as default static, but if you need more, we need to add packages. Minimal images make sure we do that with least attack surface.
I have been curious on secure base images for the AI ecosystem, where we need to ship with cuda 11.8/12.8/13.1 for stability reasons, and in our case, a bit of the torch ecosystem and Nvidia rapids ecosystem. That ends up being... A lot. Extra fun: going all the way to FIPS..
What is the process to trust the usage of this?
How can we learn the identity of the contributors? How are the contributors vetted? How are we notified if a significant change in leadership happens?
It's just a general problem when relying on GitHub accounts for important code.
For some reason I trust the big vendors to have better safe-guards against things like the questions above. Such as aws linux containers etc..
Would love to hear how other people think around this.
I am pushing myself to learn nix and get rid of base images altogether.
The syntax is hard without a functional background but I strongly believe this is the next logical step to harden containers and have reproducible builds.
I'm not sure what problem this is solving. This seems like chainguard but being built in "your ci" (github) vs "their ci". Images may be a bit smaller, but this is already a feature set that wolfi already allows for. Besides that chainguard is not full-source bootstrapped.
From reading the project readme, I think this demonstrates creating any image you want using Chainguard's tools including commercial ones.
Why does this not use chisel? I assume you at least drop the bin dir? Although the presence of ncurses is super weird
I don't understand why one would go halfway and leave packages which are unneeded for services. The only executable in a hardened container image should be your application.
Thanks! but these are builder images, not the final runtime. Chisel only really makes sense after the binary is built and you know what it needs at runtime. Before that you are pulling in whole packages, which is why things like ncurses might show up, similar to chainguard's image. For a builder, it is just SBOM noise and not something the app ever executes. Its hard to identify what you need before running the application, and you can always find a library you don't need. The “only your app should be executable” idea works for fully static binaries, but once you use glibc or CGO you already have other executables.
Then why are these labelled as "production" ready?
And surely redis is a runtime image?
Looks very useful, we should definitely build up on this!!!
Hard pass...
In general, a public security policy is pointless. It is the one layer you want people to trip over when breaking a system. =3
Why do you say so?
Best to look at security policy using ecological predator-prey models. If you don't, than you fall victim to the assumption a "puzzle" you can't break is unbreakable in general.
Nuisance users don't publish CVE, and a zero trust model shows you something important. =3
Joel a little offtopic but looks like we have bumped into each other 3 times now (I remember you from VM comment and then today on a different comment and now this)
I am curious to ask now but why do you end every message with =3 & when did you start with this trend, really curious now xD
Don't worry about it... =3
yeah, really curious at this point.
are these images based on debian? seems unclear as they are all framework specific..
Need more information on how I can integrate this in my pipeline but this looks promising
Fewer CVEs do not necessarily mean safety.