containers
Custom lint rules
In large organizations or projects with multiple images, it would be ideal to enforce certain standards on all bootc images. Be it certain packages are installed/enabled, hardening rules are applied or simply that it follows conventions.
It would be nice if bootc container lint allowed the administrators to drop in custom linting checks, possibly in the form of bash scripts, which are evaluated at the end of the linting process. The output of those scripts determines the result of bootc container lint. Since these scripts are stored inside the image, they will be present on downstream images too which makes these lints easy to propagate.
I'm proposing a new directory containing custom linting rules on the image, /usr/lib/bootc/lint.d/, which bootc container lint evaluates when called. This could be Bash or a proprietary syntax.
This isn't difficult to build something custom on your image, though I feel it would be beneficial to bake something into the existing linting action.
I'm weakly in favor, however - we should be clear that organizations can and probably should do scanning like this external to image builds as part of their CI pipelines.
A pattern I see a lot in the enterprise for example is around three levels:
- OS vendor (Debian, Red Hat, etc.)
- base OS group (people who speak kickstart, IP addressing and firewall rules, and are often responsible for ensuring systems are up to date and pass audit checks)
- app group (people who know how to run their app)
The people in the base OS group are often also able to control the deployment of the app group, e.g. the base OS group would be able to add into a pipeline things like Clair scanning too.
The base OS group may not be able to easily directly ensure that bootc container lint is the final thing invoked in the app team's builds though.
But yes, for cheap or required things as you say I could definitely imagine it being nice to enable the app team to just run the base OS team's checks in a plain container build.
As far as implementation we'd need to bikeshed some stuff:
This could be Bash or a proprietary syntax.
I think the basic starting point is a having /usr/lib/bootc/lints.d being a drop-in directory of executables right? The main question is if we want more structured metadata than just filename and need to have a split metadata/executable pattern like systemd unit vs ExecStart (earlier prior art: .desktop file) I think.
The other place this would be useful is a semi-replacement for virt-sysrep. Since we lose the reset ability of virt-sysprep, having the equivalent expressed as lint rules would allow us to be less heavy handed in downstream container builds by using the lint rules as guardrails instead. We are very much the base OS group referenced above, but it is infinitely easier to setup predefined pipelines with specific rules than police builds
