Manage accepted / used Access- and Artefact-Types configurable

[ccwienk]

Context / Motivation

OCM is extensible w.r.t. artefact- and access-types. Both OCM-Gear and its extensions only support subsets of access and artefact-types.

This should be formalised and accompanied by filtering and configuration options.

Declaration and honouring of accepted access- and artefact-types

• Each OCM-Gear-Extension should declare the list of supported access- and artefact-types. For special-cases (e.g. issue-replicator-extension), wildcards should be supported (e.g. .* for "any")
• it should be possible to restrict certain combinations of access- + artefact-types to match status-quo

If an OCM-Gear-Extension is asked to process an OCM-Component, it should skip any artefacts w/ unsupported (access-)types. Extensions dispatching tasks to other extensions on artefact-granularity (such as artefact-enumerator) should honour declared accepted types and not explicitly schedule unfulfillable tasks.

Configuration of OCM-Components of interest

• OCM-Gear-Extensions offering a means to configure OCM-Components to process should - in addition to specifying ocm-coordinates (name, version ..) - also offer means to filter artefact- and access-types (as counterpart to declaration of accepted types)

Observability and Robustness

OCM-Gear-Extensions should always guard against processing unsupported artefact- and access-types. For the sake of observability, OCM-Gear-Extensions should emit warnings if unprocessable artefacts are encountered. Those should be silenced via explicit cfg.

Examples

BDBA-extension might declare the following accepted types (accepted types are not exposed to end-users via cfg as they declare technical capabilities):

accept: # declare types the bdba-extension supports (users may - for varying reasons - want to further restrict actually processed types)
 - artefact-type: ociImage
   access-type:
   - localBlob
   - ociRegistry
- artefact-type: .* # as bdba will accept any blob, technically, we do not have to restrict artefact-types
  access-type:
  - localBlob
  - s3

In a OCM-Gear-Installation, a user/admin may decide to restrict actually-processed artefact-types, e.g. to ociImages and helmCharts. This cfg should be possible specifically for each ocm-gear-extension (for example, a user might want to have malware-scans for all artefacts, but not scan everything for vulnerabilities):

filter: # todo: allow AND|OR?
  - artefact-type:
    - ociImage|helmChart # support regex (also: allow usage of either list of
    name: optional name for filtering-rule # might come in handy for logging
    on_non_acceptable: warn # | fail | ignore
    componentName: # optional (actually, all filter-attrs should be optional, although at least one should be present)
    # .. other ocm-coordinates for filtering

# if filter will yield artefacts target-ocm-gear-extension cannot process (as per their `accept`-cfg) it should be possible to configure how to handle that  case (silently ignore, warn, fail)