Improve Kubernetes scanning user experience

[itaysk]

discussed in #5725

1. Original Trivy k8s scanning UX was designed to mimic kubectl UX
2. Trivy Kubernetes scanning has a node scanning (via api) and node-collector scanning (via job).
3. As the feature set grew, the UX became unintuitive as described below

Issues raised in the linked discussion:

1. The default is intrusive which might not be a good choice for a default value. IIRC this was the choice only because the default of --components` needed to be all-inclusive.
2. --components workloads includes some cluster-level checks (which isn't semantically correct).
3. no way to do non-intrusive infra scan.
4. no way to do RBAC-only scan, also RBAC is mentioned as a component type, which is a bit confusing.

when designing a solution, we should consider the following k8s scanning features:

1. scan containers for vulnerabilities
2. scan workloads for misconfigurations
3. scan cluster components for misconfigurations via k8s api
4. scan cluster components for misconfigurations via node collector
5. scan cluster resources like RBAC
6. scan cluster components for vulnerabilities via kbom

Proposed solution

trivy k8s context is the basic command template, like all other Trivy targets. Today we allow kubectl-like experience like kind/resource positional and --namespace flag in addition to a pseudo resource called cluster; these will be removed. There will be only one positional which is the cluster connection, and further refinement will be through target-specific flags. the positional will be a reference to a kubeconfig context, which is quite standard. if not provided the default kubeconfig and default context will be used, so trivy k8s will still work.
Additional flags to refine the target: --include-namespace/--exclude-namespace --include-kind/--exclude-kind --skip-images --disable-node-collector`

examples

scan results	old command	new command
full results finding from cluster	trivy k8s cluster	trivy k8s
full results finding from cluster without node misconfiguration	n/a	trivy k8s --disable-node-collector
results from cluster without node collector or images	n/a	trivy k8s --report summary --disable-node-collector --skip-images
result finding only from specific resources including images	trivy k8s cluster --component workload	n/a (unable to select specific resource)
result finding only from user apps resources	n/a (--component workloads was not accurate)	trivy k8s --skip-images --exclude-namespace kube-system --exclude-kind node,clusterrole,clusterrolebinding
full result finding only from Infra resources	n/a (--component infra was not accurate)	trivy k8s --include-namespace kube-system
results of infra Resources without running node-collector	n/a	trivy k8s --include-namespace kube-system --disable-node-collector
rbac assesment infra only	n/a	trivy k8s --include-namespace kube-system --include-kind role,clusterrole,rolebinding,clusterrolebinding
rbac assesment user rbac only	n/a	trivy k8s --exclude-namespace kube-system --exclude-kind clusterrole,clusterrolebinding
compliance report cis	trivy k8s --compliance=cis	trivy k8s --compliance=cis
compliance report cis without node level checks	n/a	trivy k8s --compliance=cis --disable-node-collector
compliance report nsa /pss	trivy k8s --report summary --compliance=nsa	trivy k8s --compliance=nsa (--disable-node-collector can be added)
kbom	trivy k8s --format cyclondx	trivy k8s --format cyclondx

Tasks :

• trivy k8s: --skip-images flag #6193
• trivy k8s: --disable-node-collector flag #6194
• trivy k8s: new flags --include-namespaces and --exclude-namespaces #6195
• trivy k8s: new flags --include-kinds and --exclude-kinds #6196
• trivy k8s: update user experience docs #6199
• trivy k8s: remove cluster and all args and unused flags #6467

[nika-pr]

Much appreciated @itaysk!

[simar7]

@itaysk after reading this, my understanding is that the --include-namespace and the --exclude-namespace flags in the new UX are there to explicitly specify the namespaces to include or exclude. This was done to make the scanning "less intrusive" for the reasons you mentioned above.

To be clear, passing these flags would also implicitly need (or not) the required permissions. For example, if --include-namespace kube-system is passed in by the user to do an infra scan, it would be necessary to provide Trivy with the right set of cluster level perms in order for the scan to succeed.

Similarly, if --exclude-namespace kube-system was passed in, Trivy will not require and cluster level perms and only scan user workloads/apps.

Have I got that right? cc @afdesk

[itaysk]

--include-namespace and the --exclude-namespace flags ... This was done to make the scanning "less intrusive"

to clarify, when I wrote "intrusive" I meant doing something more than API calls, like node collector.
I don't think namespace flags specifically are the related to intrusiveness, it was part of the overall CLI UX change
also, I don't think we eventually made the default experience less intrusive since node collector still runs by default.

To be clear, passing these flags would also implicitly need (or not) the required permissions

true. @afdesk worked on documenting the needed permissions for each trivy k8s use case. I don't remember if it was concluded

--exclude-namespace kube-system was passed in, Trivy will not require and cluster level perms and only scan user workloads/apps

yes, namespace selection was added to allow the user to scope trivy to their specific use case

---

BTW I don't think this PR description accurately represents the eventual UX we ended up with. it started with me capturing and analyzing the feedback, then Chen added design details, and later implemented it in several PRs, I think by now it's not the most coherent description of the current state. Also I think we can close this issue and if needed open specific ones.