docs(proposals): Add proposal to extend pluggable scanner spec#285
docs(proposals): Add proposal to extend pluggable scanner spec#285Vad1mo wants to merge 1 commit into
Conversation
Signed-off-by: Vadim Bauer <vb@container-registry.com>
| - `policy` / `attestation` — OPA/Rego, Kyverno; consumes any prior report | ||
| - Vendor-prefixed: e.g. `x-acme.binary-provenance` | ||
|
|
||
| 2. **Declared inputs** *(optional, default = none)*. Add `consumes_capabilities: []string` to `ScannerCapability` so Harbor can build a DAG. Default empty ⇒ standalone scanner, current v1.2 behavior. |
There was a problem hiding this comment.
Can you please explain what is DAG and its data structure? how it is generated, and where should it be stored, and how it controll the behaviour of the scanner adapter?
|
|
||
| ### Harbor Core Changes (all additive) | ||
|
|
||
| 1. **N scanners per project (additive).** Keep the existing `project_scanner` single-binding row as the "primary scanner" for backward compatibility. Add a `project_scanner_binding(project_id, registration_uuid, capability_types[], priority, enabled)` join table alongside it. Projects that never use the new UI continue to behave exactly as today. `getScannerOfProject` returns the primary; a new endpoint returns the full binding list. |
There was a problem hiding this comment.
For N scanners per project, there should be a new table project_scanner, how the application matches the scanner with specified configuration, if there is multiple scanner configured, is there any fallback mechanism when the first scanner failed?
|
|
||
| ### Harbor Core Changes (all additive) | ||
|
|
||
| 1. **N scanners per project (additive).** Keep the existing `project_scanner` single-binding row as the "primary scanner" for backward compatibility. Add a `project_scanner_binding(project_id, registration_uuid, capability_types[], priority, enabled)` join table alongside it. Projects that never use the new UI continue to behave exactly as today. `getScannerOfProject` returns the primary; a new endpoint returns the full binding list. |
There was a problem hiding this comment.
In current Harbor UI, the capability is limited in the UI, when there are new capability configured, How the UI enable this capability, for example, when a secret scanner configured, How does the user access the feature scan secret in the UI dynamically?
|
|
||
| 8. **CLI/automation (additive).** Existing `harbor artifact scan` invocations behave identically. New flags: `harbor scanner list-capabilities`, `harbor artifact scan --capability dockerfile.reconstruct`. | ||
|
|
||
| ### Example Chained Flow |
There was a problem hiding this comment.
can you take the license scan as an example, draw a whole picture flow diagram to include all interaction during this process?
5 participants
Adds a new proposal under
proposals/new/extend-pluggable-scanner-spec.mdthat proposes a backward-compatible v1.3 revision of the pluggable scanner spec (current: v1.2.0, June 2024) and a set of additive Harbor core changes to turn the scanner subsystem into a general-purpose image-analysis plugin framework with chaining.The proposal opens the capability namespace (Dockerfile reconstruction, lint, helm.analyze, license, secret, malware, policy, attestation, etc.) and lets adapters declare
consumes_capabilitiesso Harbor can build a DAG of analyzers — output of one feeding the next.Related