Trivy operator transfer data a lot through NAT gateway #1744
Comments
|
@chary1112004 Trivy-operator v0.18.0 use SBOM cache and reduce the amount of download of image scan. |
|
@chen-keinan thank you for suggestion. We will upgrade to v0.18.0 and verify it. Thanks! |
|
@chen-keinan I would like to have question, what happen for images that are already downloaded and running in kubernetes during scanning. Does trivy download image inside before it starts scanning? Thanks! |
its depend on which node the images where downloaded , if its on the same node then trivy will re-use. Note: if you use filesystem scan command then images will not be downloaded however it require privileged access |
|
@chary1112004 do you still want to keep this issue open ? |
|
@chen-keinan I just come back this to verify. I will keep update once it works for us so please keep it open for now! Thanks! |
|
Hi @chen-keinan, I work with @chary1112004. I was looking for documentation about the
If I run trivy locally then the filesystem scan command is clear to me, but if I set Can you provide some clarification on this? The documentation is not clear enough I think. Thanks in advance. |
|
@aarontavio using see here the differences between fs vs. rootfs support |
|
@chen-keinan could you please give us more explain about trivy.command = rootfs with filesystem and image since when we use trivy.command. = filesystem and it generates issue in #1792? Thanks! |
command = Image: download the image from registry |
Yes, you explain about image and filesystem before. I would like to ask about option rootfs. |
@chary1112004 see this comment |
@chen-keinan I could see the rootfs also scan the same what image scan. What I would like to ask that is rootfs download the image from registry (same as image) or scan the local downloaded image on node (same as filesystem). Thanks! |
|
yes, thanks. We will try with rootfs and see if it works for us. |
@chen-keinan We have switched to PS: We also have re-tested with For example:
|
|
@chen-keinan I also saw there is option value file offlineScan: false https://github.com/aquasecurity/trivy-operator/blob/main/deploy/helm/values.yaml#L373. Could you please explain how it works for enable offlineScan:true for the case command: image? Thanks! |
this flag is if you want to scan |
|
@chen-keinan thanks, if we use Thanks! |
yes , it schedule it on specific node |
Thank you, it could probably that we have gitlab runner pod ( Thanks! |
|
@chary1112004 do you still want to keep this issue open ? |
|
Hi @chen-keinan, thanks for the interest and the effort. we could verify that after setting So I guess the data transfer problem is solved. What we have also experienced, a couple of times already, is when the See pod events: This obviously happens whenever the image is not present in the node for some reason. Since the Another option would be that the operator notices this and kills the scanning pod so that the process can continue scanning other images. UPDATE: I just saw that after some minutes the ErrImageNeverPull pod disappears and the scanning process continues automatically. We have to investigate why this happens but it does not seem to be a show-stopper for us. Maybe this should be another ticket. Do you have any idea that can help on this? |
@chary1112004 Please do open another issue (to have the discussion more accurate for community as well) for it and you can close this one if not relevant anymore |
@chen-keinan yes, I am going to open another ticket for above issue. Thanks for your support! |
What steps did you take and what happened:
Hi,
Currently we detect trivy operator transfer data through NAT gateway (we are using AWS) quite amount data then it really cost.
Every time pod scan-vulnerabilityreport-* is started then it download/connect to amount of docker images. Does trivy operator support cache or database to re-use without download?
Helm chart installed: https://artifacthub.io/packages/helm/trivy-operator/trivy-operator/0.3.0
Any suggestion to resolve this issue would be very much appreciated!
Thanks
Environment:
trivy-operator version): 0.3.0kubectl version): 1.25The text was updated successfully, but these errors were encountered: