skip to content

What does a `trivy k8s` run in Trivy 0.74 read and create in a cluster, and how do you keep its report usable?

level: seniorimportance: nice to knowfreq 9%

answer

  1. manifests, images and components
  2. a job on every node
  3. list rights across five API groups
  4. all versus summary
  5. namespace and kind scoping

basics

~20 s

trivy k8s lists cluster resources through a kubeconfig context, scans each workload image and manifest, checks RBAC and control-plane component versions, and by default runs a node-collector job on every node. --report summary and namespace or kind filters keep the output readable.

solid answer

~40 s

In Trivy 0.74, `trivy k8s [CONTEXT]` (experimental) uses the kubeconfig's context, lists resources and scans with `vuln,misconfig,secret,rbac` by default: manifests for misconfigurations and secrets, role bindings for RBAC issues, control-plane and node component versions for vulnerabilities, and each workload image, pulled from the scanning machine with credentials detected from image pull secrets. Its identity needs `list` on all resources in the core, `apps`, `batch`, `networking.k8s.io` and `rbac.authorization.k8s.io` groups, plus rights to create and delete jobs and create a namespace, because a **node-collector** job runs on every node in `trivy-temp` unless `--disable-node-collector` is set. The `--report` flag takes `all` or `summary`; its default in 0.74's flag definition is `all`. Scope with `--include-namespaces`, `--include-kinds` or `--skip-images`.

code

bash · 5 lines
bash
trivy k8s --report summary \
  --include-namespaces payments,checkout \
  --disable-node-collector \
  --format json -o k8s-summary.json \
  staging-cluster

go deeper

for a junior

Recall that trivy k8s scans both the manifests and the images they reference, using your current kubeconfig context.

for a middle

Explain the four default scanners, the all and summary report modes, and the namespace and kind filters that scope a run.

for a senior

Prepare the identity: list rights, the node-collector's job and namespace rights, registry access for images, and when to disable the collector on production.

for a principal

Choose between point-in-time trivy k8s runs and an in-cluster operator, weighing scan identity privileges against continuous coverage.

## What a run touches `trivy k8s` (alias of `trivy kubernetes`, marked **experimental** in 0.74) scans a live cluster from outside it. Given an optional context name, it uses the default kubeconfig or the one passed with `--kubeconfig`, and then: 1. **Lists resources** across the cluster: workloads, roles and bindings, network objects. 2. **Scans each manifest** for misconfigurations and exposed secrets, separately from the image it references. 3. **Pulls and scans each workload image** for vulnerabilities and secrets, using the same `--image-src` order as `trivy image`, with registry credentials detected from the workloads' image pull secrets and service accounts. 4. **Matches control-plane and node components** (API server, kubelet, kube-proxy and others) against a Kubernetes vulnerability feed. 5. **Schedules a node-collector job** on every node, by default in the `trivy-temp` namespace with the `ghcr.io/aquasecurity/node-collector:0.3.1` image, to read node configuration for the infrastructure assessment. For continuous scanning from inside the cluster, Aqua ships a separate project, the Trivy Operator; `trivy k8s` is a point-in-time run. ## The identity it needs - `list` on all resources in the core group, `apps`, `batch`, `networking.k8s.io` and `rbac.authorization.k8s.io`. - For the node-collector: `get` on `nodes/proxy` and `pods/log`, `watch` on events, `list`, `get`, `create`, `delete` and `watch` on jobs, and `create` on namespaces. That second set is the surprise: by default a "scan" creates workloads. `--disable-node-collector` removes the job, and with it the node-level findings; `--tolerations` lets the job run on tainted nodes, and `--exclude-nodes` skips nodes by label. ## Default scanners | Scanner | Applied to | |---|---| | `vuln` | workload images, control-plane and node components | | `misconfig` | resource manifests and, through the node-collector, node settings | | `secret` | workload images and manifests | | `rbac` | roles and bindings | All four are on by default for this subcommand, unlike the `vuln,secret` default of `trivy image`. ## Report modes and scoping - `--report` takes `all` or `summary`. The flag's default in 0.74's source and CLI reference is **`all`**, while the target page's prose describes the summary view as the default; the code wins, so pass `--report summary` explicitly when a cluster-wide overview is wanted. - `--format` accepts `table`, `json` and `cyclonedx`; the last one produces a cluster bill of materials. - `--include-namespaces` or `--exclude-namespaces`, and `--include-kinds` or `--exclude-kinds`, narrow discovery; each pair is mutually exclusive, and excluding namespaces works only for an identity with a cluster role, because Trivy must list every namespace to subtract some. - `--skip-images` skips pulling and scanning workload images when only configuration matters. ## Reading the output - The **summary** view gives counts per resource and scanner, suited to a first look across many namespaces. - The **all** view lists each finding; the docs recommend it for multi-container pods, because the JSON summary cannot tie a result to one image within a pod. - Findings for a workload image and for the manifest that references it are reported separately, so a rebuilt image and an unfixed manifest are tracked independently. ## Operating it safely - Use a dedicated kubeconfig context bound to the roles above, not an administrator's context. - `--qps` (default 5) and `--parallel` (default 5) bound the load on the API server and the scanning machine. - The scanning machine needs network access to every registry the cluster pulls from, and enough disk for the images. - Built-in `--compliance` reports exist, but interpreting benchmark controls is a compliance subject of its own.

  • Why might a platform team pass `--disable-node-collector` on a shared production cluster?
    By default the scan schedules a job on every node in the `trivy-temp` namespace, so its identity needs rights to create jobs and namespaces. Disabling the collector drops those rights and the node-level infrastructure findings, leaving manifests, RBAC, components and images to the list-based scan.
  • Where does `trivy k8s` get credentials for private workload images?
    It detects them from the workloads' image pull secrets and service accounts and adds any registry options passed on the command line. The images are pulled by the machine running Trivy, so that machine needs a network path to each registry; `--skip-images` avoids the pulls altogether.

saying these in an interview costs you the question

  • trivy k8s only reads from the API server and creates nothing.
  • trivy k8s checks manifests only; images need separate trivy image runs.
  • Omitting --report always gives the summary view.
  • --exclude-namespaces works for an identity bound to a namespaced role.
  • trivy k8s runs continuously once started, like an operator.