ROX-13794: Add content sets to Components proto - #1053
Conversation
|
Images are ready for the commit at a2c102b. To use the images, use the tag |
|
/retest |
|
@jvdm: The following test 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. |
vikin91
left a comment
There was a problem hiding this comment.
The code look great. The change is okay as well, but let me propose an alternative to it.
Adding the field will mainly have influence on the Scanner repo, as scannerV1.Components proto will be translated into a stackrox proto type when we merge #3757 - see func protoComponentsFromScanComponents(c *nodes.Components) *storage.NodeInventory_Components in #3757.
As the life of scannerV1.Components will be short within the scope of stackrox code (only few lines in the inventorizer.go) we might as well return the content sets as an additional parameter from Analyze - would that maybe help keeping things cleaner in the component.proto?
I am glad you guys are moving in that direction. As I mentioned in the description:
I also saw the following comment in the PR: 👍
I want so suggest we do one the following:
And we won't need (1.) would be closer to the actual use case of |
|
See follow up changes at: #1055 |
|
I have a follow-up to this change: #1059 |
Description and rationale
Add a field to
scannerV1.Componentsto carry the list of Content Sets found in a node inventory scan.scannerV1.Componentis used by Compliance node inventorizer to send the list of components detected in a node inventory scan. The Scanner initially used that payload to hold CPEs mapped during the detection/analysis phase. But to map CPEs, Scanner needs access torepository-to-cpe.json. Compliance doesn't have access to that file, yet.To avoid adding one additional channel to Compliance to keep repo-to-CPE data up-to-date, we will return the Content Sets found in the node. That will allow Scanner to do the mapping when Central calls Scanner's GetNodeVulnerabilities().
Why
scannerV1.ComponentsBecause content sets are currently attached to a single O.S. installation or an image layer for node scanning. This is acceptable for nodes because there are no layer compositions. But for images, this might be limiting. I foresee the possibility of multiple images adding different content sets, and it will be hard to tell, com
scannerV1.Componentswhich ones are for each package. But hopefully, this field will be ignored by image scanning.By using
scannerV1.Componentsas part of the node inventory scan, I feel we are coupling image scanning with node scanning concerning the design of the proto message.I am open to discussing alternatives.
Tests