Our Community Images project has been a huge success with more than 1.3M downloads of our hardened containers in just a few months. The Docker Hub community has been very welcoming and we’re just getting started with this project.
Because of the rising interest, we thought we’d walk through our selection criteria and hardening process so you can better understand how the project works and know what you’re getting when you download one of our images.
We’ve written fairly extensively on our blog about container hardening and our approaches, but we’ll provide a brief overview of the hardening process so you understand what it is that we’re offering to the community.
Our hardening platform, RapidFort, assesses how a container is used and what files are touched during normal operation. The assessment tracks what code in the container is used and what isn’t. RapidFort automatically deletes code that isn’t used, which reduces the size, attack surface, and number of vulnerabilities related to that container. On average, we see up to 90% reduction in attack surface and up to 99.9% reduction in vulnerability counts. (It’s worth noting that RapidFort also allows for manual code deletion, custom profiles, and intelligent dependency tracking.)
For the Community Images, we use coverage scripts to exercise a container's normal operation. Pre-hardening container assessments are usually done by monitoring the production and pre-production operations of a container, but we don’t run all the containers we are hardening in the Community Images project. So, we use the coverage scripts and tell RapidFort to automatically delete what’s not used.
We want to provide the biggest value possible to the container community, but we can’t simply take every popular image from Docker Hub and harden it. Containers must meet certain criteria before we select it to harden and give back to the community.
First things first: every container can be hardened, but not every container is appropriate for general-purpose hardening. We look for what we call “leaf containers.” These are containers for which we know we can write coverage scripts to exercise their primary functions. We can’t do a general-purpose hardening of something as large as Ubuntu (an entire operating system) or Python (an entire programming language) because their use cases are too broad.
We differentiate leaf containers from base images by considering how and why people download them. Base images provide a foundation for an additional layer of deployed software. This layer is usually proprietary or customized to the organization deploying the container. As such, they would need their own customized coverages scripts to exercise the functionality they need to understand how to harden that container.
We look for containers with specific and bounded use cases. For example, it makes sense to harden NGINX or Redis because we have a good idea of what people need from those containers. We can write coverage scripts that exercise their main functions. Our coverage scripts are open source and anyone can contribute if they would like to see additional functions exercised.
Open source software is built on transparency, accountability, and community involvement. We are big proponents of the open source software movement and want to give back more than we take. Not only are all of our hardened container images free for anyone to use, but anyone can see the results of our hardening process, improve our methodology, and be part of the effort.
On our Community Images Github readme page is a table that shows all the images we provide with a link to the RapidFort optimization report (see the green “Get full report” button in the screenshot above). As of this writing, the PostgreSQL RapidFort report shows:
These statistics demonstrate the levels of optimization we were able to achieve using our coverage scripts.
We also provide granular statistics and details about the vulnerabilities we’ve removed and which remain. You can see in this screenshot that:
The numbers above the bars in the chart on the right show the vulnerability counts in the original image.
We use automation to track every time a popular container is updated. Within 24 hours, we download the new container, harden it, and release it.
Vendors typically release new containers when they have new software versions to release or when there’s a new patch available. You can rest assured that our Community Images repository will always have the latest and greatest available with all of the known patches applied.
Our containers don’t contain any patchable vulnerabilities. Whatever is left in the image is left for the user to manage, but we take out a huge amount of the guesswork that typically goes into vulnerability management.
There are various ways you can get involved if you’d like to do so. The easiest thing to do is to start using our hardened images. We ask for nothing in return; we’re just hoping to make the internet safer.
If you’d like to be more actively involved, here are some options:
You can learn more about the RapidFort container hardening platform by looking through the reports on the readme page, or you can sign up for our free tier and get started with your own optimization efforts. Reduce your software attack surface by up to 90% with RapidFort.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。