Will there be a replacement functionality for kind/resource for k8s scans?

[coffeemakingtoaster]

Description

The recent update to version 0.51 updated the UX for Kubernetes scanning. While I do agree that the new approach is more intuitive and less confusing, I was wondering if the kind/resource functionality will be reimplemented.

As I understand it, it is currently not possible to target resources with a specific name. This capability was available with the old approach and can be quite useful, especially when working with branches in a CI environment.

For example, previously, it was possible to achieve this by executing the command:

trivy k8s deployments/<branchname>

However, with the new UX, I don't see how to perform the same action.

Once again, I'm a fan of the recent update! I just wanted to see if there are any plans to address this particular edge case. 🚀

Target

Kubernetes

Scanner

None

[chen-keinan]

@coffeemakingtoaster currently there are no plans to re-introduce kind/resource scanning

[itaysk]

we considered that use case (scanning a single resource) rare for Trivy users. given that it didn't align with the new UX we decided to omit it. But if we see that people ask for it (for example by commenting on this discussion), we can consider re-thinking how it can fit in the new UX.

[wicastk]

I think it is necessary to allow scan 1 specific deployment, when you have a cluster with many deployments, and the output has a lot of numbers (findings), and you need to manage each deployment's findings, the flag "all" may output more than 1M lines, that definitely is not friendly to manage, based on this scenario, having separately scans (per individual deployment) you may get 1 output with specific deployment findings and allows to easily manage them instead of having to look for all results different type of scans in different places/sections within the standard log file/output (which include all cluster/namespace).

[hydrapolic]

Hello, this suprised me a bit when upgrading to newer trivy version and I needed to downgrade.

I have my k8s clusters added to Icinga2 monitoring where each component runs a separate vulnerability scan so it's easy to tell which component is vulnerable.

clusterA

• componentA - not vulnerable (green color)
• componentB - 1 low severity vulnerability (green color)
• componentC - 3 critial severity vulnerabilities (red color)

So I know exactly what needs fixing.