Lion Cipher Lab

Continuously scan a running Kubernetes cluster with Trivy Operator

• Cloud Security
• Intermediate
• ~75 min
• Free · no account required

Why it matters

Most people meet vulnerability scanning as a one-shot: point `trivy image nginx:1.20` at a container, get a list, move on. That is genuinely useful in a build pipeline, but it answers only one question at one moment -- 'was this image clean when I checked it?' It does not answer the question a running cluster actually poses, which is 'what is vulnerable in what I am running RIGHT NOW, and did it change when someone deployed something at 2am?' Clusters are not static: images get redeployed, tags drift, new CVEs are published against images that were clean yesterday, and no human is re-running…

What you'll learn

• explaining, in plain words, what a Kubernetes OPERATOR is -- an ordinary program that runs INSIDE the cluster, watches the cluster's own state through the Kubernetes API, and acts on changes automatically (a control loop) -- as opposed to a tool you run by hand from outside
• explaining what a CRD (Custom Resource Definition) is: a way to teach the Kubernetes API a new object type, so `kubectl get <thing>` works for something Kubernetes never shipped with -- here, VulnerabilityReport and ConfigAuditReport objects that the operator creates
• standing up a real, throwaway Kubernetes cluster locally and for free with kind (Kubernetes-in-Docker), so you can practise cluster-security work on a cluster you fully own
• installing Trivy Operator from its official manifest and confirming the controller is running and the new report CRDs are registered
• measuring the BEFORE state honestly: deploy a workload on a deliberately OLD image tag, then watch the operator AUTOMATICALLY produce a VulnerabilityReport for it -- with no scan command from you -- and read the CRITICAL/HIGH counts with kubectl
• reading a ConfigAuditReport: the operator's misconfiguration checks against the workload's spec (for example, that runAsNonRoot is not set), which is a different signal from image CVEs
• measuring the AFTER state: bump the image to a patched tag and add a securityContext, watch the operator RE-SCAN on its own, and record the drop in CVE counts and the cleared misconfiguration -- the measurable win
• triaging a report like a professional: sort by fixable CRITICAL/HIGH first, treat unfixable and base-image-inherited CVEs separately, and never read a raw count as a to-do list
• knowing the honest limits: a report is not a runtime block; continuous scanning costs cluster resources; the operator scans what is ALREADY deployed, not what is about to be; and this is not the same control as admission-time gating or CIS posture (Kubescape)

Steps in this lab

1. First, the idea — an operator watches, it does not wait to be asked
2. Set up: create a throwaway Kubernetes cluster with kind
3. Install Trivy Operator from its official manifest
4. BEFORE — deploy a deliberately old image and watch a report appear on its own
5. BEFORE — read the ConfigAuditReport, a different kind of finding
6. FIX + RE-MEASURE — patch the image, harden the spec, let the operator re-scan
7. When continuous in-cluster scanning is the right tool — and how a pro reads the report
8. Honest limits — what a report is not, and what it does not replace

Open the full interactive lab →