Problem
Eraser configures a single scanner for the whole cluster:
components:
scanner:
enabled: true
image:
repo: ghcr.io/eraser-dev/eraser-trivy-scanner
tag: v1.5.0-beta.1
request: { mem: 500Mi, cpu: 1000m }
limit: { mem: 2Gi }
config: |
cacheDir: /var/lib/trivy
...On a mixed-OS cluster the appropriate scanner differs by node OS. Today there is
no way to express that: image, config, request and limit are all
cluster-wide.
This became concrete with the Windows support in v1.5.0-beta.1. trivy-scanner
publishes no windows/amd64 layer, so on a mixed cluster you must either run no
scanner at all, or replace trivy everywhere with something that also works on
Windows.
Why the obvious workarounds don't hold up
Multi-platform image. Because the scanner is a single reference, a
Windows-only image is also scheduled onto Linux nodes, where containerd fails it
with parent snapshot ... does not exist. So a Windows scanner image must be
multi-platform.
One index, two implementations. An OCI index can hold unrelated images per
platform, so crane index append -m <trivy-linux> -m <other-windows> -t combined
does work today. But:
config is one blob shared by both scanners, so it has to carry both schemas
and rely on each ignoring the other's keys.request/limit are shared, so a Windows scanner inherits trivy's 1000m/2Gi
envelope whether or not it needs it.- provenance is opaque: one tag, two unrelated projects, indistinguishable from
the reference.
That's serviceable for a demo and poor for anything shipped.
Proposal
Allow the scanner component to be configured per node OS, defaulting to today's
behaviour when no override is present. Shape is yours to choose; one option:
components:
scanner:
enabled: true
image: { repo: ghcr.io/eraser-dev/eraser-trivy-scanner, tag: v1.5.0-beta.1 }
request: { mem: 500Mi, cpu: 1000m }
windows:
image: { repo: example.azurecr.io/my-windows-scanner, tag: v1 }
request: { mem: 64Mi, cpu: 50m }
config: |
...The same argument applies in principle to collector and remover, though
those ship multi-platform images built from one source, so the need is far less
pressing.
Related
Context
Raised while validating the Windows pipeline for the AKS Image Cleaner addon,
where the intended configuration is trivy on Linux nodes and a different scanner
on Windows nodes.
Problem
Eraser configures a single scanner for the whole cluster:
On a mixed-OS cluster the appropriate scanner differs by node OS. Today there is
no way to express that:
image,config,requestandlimitare allcluster-wide.
This became concrete with the Windows support in v1.5.0-beta.1.
trivy-scannerpublishes no
windows/amd64layer, so on a mixed cluster you must either run noscanner at all, or replace trivy everywhere with something that also works on
Windows.
Why the obvious workarounds don't hold up
Multi-platform image. Because the scanner is a single reference, a
Windows-only image is also scheduled onto Linux nodes, where containerd fails it
with
parent snapshot ... does not exist. So a Windows scanner image must bemulti-platform.
One index, two implementations. An OCI index can hold unrelated images per
platform, so
crane index append -m <trivy-linux> -m <other-windows> -t combineddoes work today. But:
configis one blob shared by both scanners, so it has to carry both schemasand rely on each ignoring the other's keys.
request/limitare shared, so a Windows scanner inherits trivy's 1000m/2Gienvelope whether or not it needs it.
the reference.
That's serviceable for a demo and poor for anything shipped.
Proposal
Allow the scanner component to be configured per node OS, defaulting to today's
behaviour when no override is present. Shape is yours to choose; one option:
The same argument applies in principle to
collectorandremover, thoughthose ship multi-platform images built from one source, so the need is far less
pressing.
Related
enabled, which blocks this scenario independently.
Context
Raised while validating the Windows pipeline for the AKS Image Cleaner addon,
where the intended configuration is trivy on Linux nodes and a different scanner
on Windows nodes.