Trivy Operator: A 24/7 ‘Security Camera’ for Kubernetes Vulnerability Scanning – ITFROMZERO

Table of Contents

Concerns About “Sleeping” Vulnerabilities in Your Cluster

Many Kubernetes practitioners have a common habit: scanning images thoroughly during the CI/CD stage, and if everything is green (zero errors), confidently deploying to Production. However, security is not a static state. An image that is safe today could be hit by a critical newly announced CVE (Common Vulnerabilities and Exposures) tomorrow morning.

Think back to the Log4j disaster (CVE-2021-44228). Thousands of applications running smoothly suddenly became easy targets for hackers overnight. If you only scan during the Build phase, you are completely “blind” to risks that emerge after deployment. This is why we need a continuous monitoring mechanism directly inside the Cluster.

Why Scanning During Build Isn’t Enough?

Based on operational experience, I’ve identified three reasons why traditional CI/CD workflows fall short:

CVE Velocity: On average, over 50 new vulnerabilities are discovered daily. Your image remains the same, but the global vulnerability database is updated every hour.
Misconfiguration: A clean image is useless if the YAML file allows privileged: true or runs with root privileges. This is the shortest path for hackers to take control of a Node.
Shadow IT: In large teams, someone might “conveniently” deploy an image from a personal Docker Hub for testing without going through the company’s vetting process.

Instead of manually typing trivy image [name] for every Pod, we need a fully automated solution.

Trivy Operator – An Extension of Aqua Security

Trivy Operator is more than just a scanning tool; it transforms security into a Kubernetes-native component. Instead of running as a CLI, it operates as a background Controller. It continuously monitors Cluster resources and exports reports as Custom Resource Definitions (CRDs).

Put simply: you just use kubectl get to see the security health of your entire system, just like how you check a Pod or Service.

Step 1: Environment Preparation

To get started, you need:

A Kubernetes Cluster (v1.20 or later).
Helm v3 installed.
cluster-admin permissions to install the Operator.

Step 2: Quick Installation of Trivy Operator

Using Helm is the fastest way to manage the Operator’s lifecycle. First, add the Aqua Security repository:

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update

Next, proceed with the installation. I recommend limiting the severity levels to avoid alert fatigue:

helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.severity=CRITICAL,HIGH"

The trivy.severity=CRITICAL,HIGH parameter ensures the Operator focuses only on truly dangerous vulnerabilities, helping the DevOps team prioritize their efforts effectively.

Step 3: Reading Vulnerability Reports

About 1-2 minutes after installation, the Operator will automatically trigger scans. To view an overview of existing vulnerabilities, run:

kubectl get vulnerabilityreports --all-namespaces

To inspect a specific application, such as redis-cart, use the describe command. The results will show detailed CVE IDs, the affected library, and most importantly, the Fixed Version. This is invaluable information for developers to know exactly which version they need to upgrade to.

Step 4: Checking for YAML Misconfigurations

This is one of the most valuable features. Trivy Operator automatically checks your Deployment files for security violations. Try running this command:

kubectl get configauditreports --all-namespaces

If the DANGER column shows a red number, you need to investigate immediately. These are typically errors like missing CPU/RAM limits, unconfigured readOnlyRootFilesystem, or containers running with root privileges.

Step 5: Visual Monitoring via Dashboard

Don’t stop at the command line. You should integrate this data into Grafana. Trivy Operator provides built-in metrics for Prometheus. Seeing a vulnerability chart trend downwards over time provides much-needed peace of mind for both the team and management.

Real-world Operational Experience

Based on real-world deployments, here are a few tips to keep your system running smoothly:

Resource Limits: By default, scanning can be RAM-intensive. Set resources.limits for the Operator (e.g., 500Mi RAM) to prevent it from consuming resources needed by your main applications.
Storage Management: Reports (CRDs) are stored in etcd. In clusters with thousands of Pods, etcd storage can grow quickly. Configure periodic cleanup for old reports.
Private Registry: Don’t forget to create imagePullSecrets in the trivy-system namespace so the Operator has permission to pull images from your company’s private registry for scanning.

Security is a process of continuous improvement, not a one-time task. With Trivy Operator, you have an automated monitoring system that reduces pressure on the operations team and elevates your product’s security to a new level.