[cli] Use image digest to generate vulnerability reports

[danielpacak]

Currently we use image tag and pass it to the active vulnerability scanner. This works for immutable tags, but has some drawbacks when a Kubernetes workload refers to a mutant image.

The possible solution is to get image ID / image digest from pod's container status and use it as arg passed to the vulnerability scanner. This also implies the following corner cases:

• 0 pods -> won't scan it -> exit with warning / info to scale up
• 1 pod -> scan with digest passed to the scanner
• N pods -> digest1, digest2, digest N -> schedule N scan jobs

[yashvardhan-kukreja]

Hi @danielpacak, I'd love to pick this issue up :)
I actually looked into the codebase around solving this issue and have a rough prototype ready adding this feature.
So, if you can assign this issue to me, I can clean up my prototype, raise a PR and give you a look of it 😊

[yashvardhan-kukreja]

Update: I have the PR ready (cleaned up) and with tests :D
Let me know if I should go ahead and raise it :)

[danielpacak]

That's great news @yashvardhan-kukreja Before we proceed with changes in code we should also plan for migration and backward compatibility. Ideally we should have a mechanism to fallback to the current implementation as this will turn the way we store VulnerabilityReports and associate them with built-in Kubernetes resources upside down. There are downstream integrations that rely on how it's implemented now, e.g. Octant or Lens extensions and other project that we're aware of. Maybe we should have a transition release where we store in the current format and new one where we name VulnerabilityReports by image digest.

Also, not sure how big is your draft PR, but we might want to do preliminary / smaller refactors to facilitate reviewing and to make sure we don't introduce any regression.

That said, maybe we could start a GDoc where we can address above mentioned concerns and them proceed with a fun part, which is code. WDYT?

[yashvardhan-kukreja]

Sure, let's do that 👍🏼

[danielpacak]

This project is still incubation and we don't have any formal template for proposals, but I drafted this document where we can discuss some high level design and other requirements.

https://docs.google.com/document/d/130vNBwa6Q0ZXx7xJqT41X0L5vppvSbbVfW0gmHn887M/edit?usp=sharing

[yashvardhan-kukreja]

Sure 👍🏼 , it says access denied for me though. I have requested access for it

[yashvardhan-kukreja]

Meanwhile, I guess I can still raise the PR which I cooked and mark it with "WIP" and later on, once we are done with design phase, I can augment over that PR itself. I guess that should be fine.

[danielpacak]

Sure. WIP / Draft PR is fine so long you keep it up to date with the main code branch by rebase

[kfox1111]

There's another option. I use tags but immutably. I ensure I never overwrite an immutable tag.

So, perhaps doing the scan at the ReplicaSet level and scanning by tag is fine, but keeping the shasum scanned. and then if you ever see any pods in the ReplicaSet that don't have the same shasum, then you know the immutable tag was mutated and can throw a warning.

[yashvardhan-kukreja]

Hi @danielpacak , is this issue still pending? If yes, I'd like to document the plan of the solution in the google docs link you shared above, as suggested in #587

PS: Sorry for this huge delay. Been swamped since a few months 😅

[danielpacak]

Hi @danielpacak , is this issue still pending? If yes, I'd like to document the plan of the solution in the google docs link you shared above, as suggested in #587

PS: Sorry for this huge delay. Been swamped since a few months 😅

Yes, this solution is still pending and we should start with proposals as this change has huge impact on existing integrations.
To get started you may find this diagram useful.