Original Trivy k8s scanning UX was designed to mimic kubectl UX
Trivy Kubernetes scanning has a node scanning (via api) and node-collector scanning (via job).
As the feature set grew, the UX became unintuitive as described below
Issues raised in the linked discussion:
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.
--components workloads includes some cluster-level checks (which isn't semantically correct).
no way to do non-intrusive infra scan.
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:
scan containers for vulnerabilities
scan workloads for misconfigurations
scan cluster components for misconfigurations via k8s api
scan cluster components for misconfigurations via node collector
scan cluster resources like RBAC
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
discussed in https://github.com/aquasecurity/trivy/discussions/5725
Issues raised in the linked discussion:
--components workloads
includes some cluster-level checks (which isn't semantically correct).when designing a solution, we should consider the following k8s scanning features:
Proposed solution
trivy k8s context
is the basic command template, like all other Trivy targets. Today we allow kubectl-like experience likekind/resource
positional and--namespace
flag in addition to a pseudo resource calledcluster
; 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, sotrivy k8s
will still work. Additional flags to refine the target:--include-namespace/--exclude-namespace
--include-kind/--exclude-kind
--skip-images
--disable-node-collector`examples
cis
cis
without node level checksnsa /pss
Tasks :