How do you scan Kubernetes clusters for vulnerabilities and misconfigurations using Trivy?

Think of Trivy scanning a Kubernetes cluster like a building inspector who walks through every floor of an office building, checking each room for fire code violations, structural issues, and unauthorized modifications. The inspector does not just look at the blueprints (manifests) but examines the actual rooms as built (running containers). The trivy k8s command is a one-time inspection visit, while the Trivy Operator is a permanent on-site inspector who checks every new tenant as they move in and continuously monitors for emerging issues.

Trivy provides native Kubernetes cluster scanning through the trivy k8s command, which connects to the cluster using the current kubeconfig context and systematically analyzes every accessible resource. The scan covers multiple dimensions: container image vulnerabilities in running pods, Kubernetes manifest misconfigurations such as containers running as root, missing resource limits, or exposed hostPath volumes, RBAC over-permissions where service accounts have cluster-admin level access, and network policy gaps. When you run trivy k8s --report summary against a production cluster, Trivy enumerates all namespaces, pulls the image references from pod specs, scans those images against CVE databases, and simultaneously evaluates the Kubernetes resource configurations against a built-in set of security checks derived from CIS Kubernetes Benchmarks and NSA Kubernetes Hardening Guidance.

Under the hood, Trivy uses the Kubernetes client-go library to authenticate and query the API server. It fetches resource manifests for Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Pods, Services, Ingresses, NetworkPolicies, Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. For image scanning, it resolves image digests through the container registry, downloads and caches image layers, and performs the same vulnerability analysis as trivy image. For misconfiguration detection, Trivy evaluates each resource against Rego policies that check for security anti-patterns. For example, in the payments-api deployment, Trivy would flag a container spec that lacks securityContext.runAsNonRoot, missing readiness and liveness probes, or a service account mounted with automountServiceAccountToken not set to false. The scan produces a comprehensive report that maps findings to specific resources with namespace, kind, name, and container details.

The Trivy Operator takes this scanning model and makes it continuous by deploying as a Kubernetes operator using CustomResourceDefinitions. Once installed via Helm chart, the operator watches for new or updated workloads and automatically triggers scans. Results are stored as VulnerabilityReport and ConfigAuditReport custom resources within the same namespace as the scanned workload. This means you can query scan results using kubectl, integrate them with Kubernetes-native monitoring and alerting, and build custom controllers that react to findings. For the checkout-service namespace, running kubectl get vulnerabilityreports -n checkout lists all vulnerability findings for workloads in that namespace. The operator also supports CIS Benchmark scanning of the Kubernetes infrastructure itself, checking kubelet configurations, API server flags, and etcd encryption settings on the node level.

A critical gotcha when scanning clusters is permission scope. The trivy k8s command requires read access to all resources across all namespaces for a complete scan, which means the kubeconfig user or service account must have cluster-wide read permissions. In multi-tenant clusters where teams manage their own namespaces, a cluster-wide scan may expose resources that the scanning user should not see. Use the --namespace flag to scope scans to specific namespaces, or deploy the Trivy Operator with namespace-scoped RBAC if full cluster access is not appropriate. Another common issue is scan performance in large clusters. A cluster running 500 pods with 200 unique images can take 30 minutes or more for a full scan because each unique image must be downloaded and analyzed. The Trivy Operator mitigates this by caching results and only rescanning when image references change. Finally, be aware that trivy k8s scans the declared image tags, and if a tag like latest has been updated in the registry but the running pod still uses the old digest, the scan results reflect the current registry state, not the actually running binary.