feat: image checker extension API

[feloy]

What does this PR do?

This PR defines and implements the API for Image Checker providers.

An extension registers as an Image checker, by calling the following function, passing a Provider object and optional metadata:

  registerImageCheckerProvider(
      imageCheckerProvider: ImageCheckerProvider,
      metadata?: ImageCheckerProviderMetadata,
    )

The provider object needs to define a check method, which will be called by the UI:

  export interface ImageCheckerProvider {
    check(image: ImageInfo, token?: CancellationToken): ProviderResult<ImageChecks>;
  }

The check method returns a list of image checks results.

  export interface ImageCheck {
    name: string;
    status: 'success' | 'failed';
    severity?: 'low' | 'medium' | 'high' | 'critical';
    markdownDescription?: string;
  }

  export interface ImageChecks {
    checks: ImageCheck[];
  }

What issues does this PR fix or reference?

Fixes #4697

[benoitf]

AFAIK the provider goal is to provide only functions so I don't see name and categories there ?

[benoitf]

I think checkImage is missing a cancellationToken: CancellationToken parameter to cancel the check

[feloy]

The name is what the UI can display for this provider, for example "Image OpenShift Analyzer". The categories indicates to the UI which are the different categories of tests the checker will run, so the results can be classified in these categories (for example USER directive, RUN Directive, Expose directive)

[benoitf]

it looks that from design perspective, the static fields are passed on the registration method

example of contract:

registerCodeActionsProvider(selector: DocumentSelector, provider: CodeActionProvider, metadata?: CodeActionProviderMetadata): Disposable;

From end user perspective, I don't really understand at all the goals of USER, RUN or Expose directive

I mean, I launch a check on the image so if the provider is there it'll do the check, else it won't.

then, if the checker is not able to analyze some images it's more a selector/filter parameter

About the name, it's part of the Result no ?

[feloy]

In this example, the name would be OpenShift Checker, the UI needs to know it before to start the tests, to be able to display it in the tab.

For the categories, they would be Container User and Exposed Ports, so the UI can display them without any failed / passed mark, the time the checks are executed, then they are updated with passed / failed. But I perhaps misunderstood the design doc.

[benoitf]

I read again draft of the spec

For categories, something like 'Container User' or 'Exposed Ports' are only known by the checker and to me it's part of the result of the scan, not part of the registration.

Until we didn't launch a scan, nothing is displayed except that we're processing.

In this example, the name would be OpenShift Checker, the UI needs to know it before to start the tests, to be able to display it in the tab.

what we can do for that is to give an extra argument when registering the provider with metadata

registerImageCheckerProvider(imageCheckerProvider: ImageCheckerProvider, metadata?: ImageCheckerProviderMetadata): Disposable;

and in the metadata you can specify a readonly name

without the name, we can assume the provider will take the name of the extension

so if your extension is named 'OpenShift Checker' then it'll use that name as well

Now if I look at the signature of the provider, it should return a ProviderResult result (or ImageCheck as the type we want is ImageCheck, result is just from what we call)

then if I look at Trivy extension result

I got them classified/sorted by severity

but if I look at

  export interface ImageCheckPartialResult {
    category: string;
    description: string;
  }

  export interface ImageCheckResult {
    status: string;
    partialResults: ImageCheckPartialResult[];
  }

(a partial result indicates a failing check on the image).

I don't get the why a partial result would be a failed result. I assume partial result is that I don't have all the result, not that it failed

so looking back at trivy results and openshift checker, it looks like I need a severity (like using a wrong EXPOSE stuff might be less critical than using an image with root user)

I would probably need some markdown result like if it passes the test

and then probably a score or grade if it fails.

my image is Grade A, grade B, grade C etc depending on the check

[feloy]

thanks @benoitf for your feedback. I'll make changes based on this

[feloy]

@benoitf how do we want to proceed for integrating this API into main? Do I continue to work on the implementation of the API and the UI on this same PR?

[benoitf]

@feloy you can use a branch in your forked repository but to move forward, we should have one PR about the API d.ts and its implementation and other PR for UI side.
Also other PRs for the extension itself but it'll be in a separate repository

[benoitf]

it should be removed