ROX-16919: [ADR] Local Scanning with Scanner V4#7276
Conversation
|
Images are ready for the commit at 8c0ba7e. To use with deploy scripts, first |
|
|
||
| 1. This method eliminates the need to store Index Reports in the central cluster for images obtained from the secured cluster. Instead, it distributes the workload of adding, storing, and retrieving Index Reports in the central Scanner's database across a large number of secured clusters connected to the Central. | ||
| 2. Re-scanning continues to rely on Deployment Resyncs. That means images are only rescanned after a resync deployment message is sent to Sensor, and the image cache has expired. | ||
| 3. The new Matcher API opens the door for Scanner in Matcher mode to provide vulnerability matching with multi-tenancy, where multiple Central instances could connect to a fleet of Matcher instances behind a load balancer backed by a DB to create vulnerability reports. |
There was a problem hiding this comment.
As we might have fleet of matchers (I don't know when that will happen), will we need a database for each matcher to store index report ( like Consequence 1 describes)? Or we just use central db to store index reports so multiple matchers can all access same central db.
There was a problem hiding this comment.
My understanding is that Matchers need a DB to keep the vulnerability data. I am describing the possibility of Vulnerability Matching happening in a single DB outside Central, front-ended by a fleet of Scanners in Matcher mode. I haven't thought too much about how we can make the DB scalable to accommodate matching requests from multiple Central instances.
There was a problem hiding this comment.
Is this flow new? I'm not seeing a getImages() call from Central to Sensor. The enricher within Sensor calls getImages() (which triggers scans but the flow is the opposite direction - Sensor will call ScanImageInternal or EnrichLocalImageInternal)
There was a problem hiding this comment.
The diagram might be confusing. I am trying to show that the messages directed towards Sensor will be handled by calling enricher.getImages() inside Sensor. Central will send MstToSensor message to Sensor, which will eventually be processed by the enricher of the detector. The method enriched.getImages() will be called by various flows, triggered by different message types, in the detector, to perform the retrieve image scans.
There was a problem hiding this comment.
Checkout Frame 2 in the miro board this image can from - believe it may be more accurate for consideration
Co-authored-by: David Caravello <119438707+dcaravel@users.noreply.github.com>
|
@jvdm: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Description
A Scanner Indexer will run in the secured clusters, akin to today's scanner-slim. That indexer needs to perform scanning of local images from the local registries and send the IndexReport data to Central so that Central's Matcher can pull that information and perform vulnerability matching, and store the results so Central can query through Scanner APIs.
Checklist: N/A
Testing Performed
N/A