DOCSEARCHbyAlgolia
Submit Docs

Trivy Operator

repository·main·Indexed 23 days ago

https://github.com/aquasecurity/trivy-operator

A Kubernetes-native security toolkit that automates continuous security scanning of cluster workloads and infrastructure. It leverages Trivy to provide vulnerability scans, configuration audits, exposed secret detection, RBAC assessments, infrastructure assessments, and compliance reports (including CIS and NSA standards), surfacing all results as Kubernetes Custom Resource Definitions (CRDs).

Tokens
62.4K
Snippets
82
Records
158
Agent score
83%

What's inside trivy-operator

  1. Available Trivy Operator security scan types

    main

    The Trivy Operator provides several types of Kubernetes workload scanning:

    • Vulnerability Scans: Scanning workloads for known vulnerabilities.
    • Configuration Auditing: Auditing Kubernetes configurations against security best practices.
    • Compliance Reports: Generating reports to verify compliance with specific standards.
    • CRD Reports: The operator generates various Custom Resource Definition (CRD) reports to store scan results, including VulnerabilityReport and ConfigAuditReport.

  2. What is an InfraAssessmentReport

    main

    An InfraAssessmentReport is a Kubernetes Custom Resource Definition (CRD) that contains security checks performed by Trivy against Kubernetes infrastructure core components (such as etcd, apiserver, scheduler, and controller-manager).

    These checks are based on Kubernetes CIS Benchmarks and other security controls. Each report is owned by the underlying Kubernetes object it scans and is stored in the same namespace as that object, following the <workload-kind>-<workload-name> naming convention.

  3. What is Trivy Operator and how does it work?

    main

    Trivy Operator is a Kubernetes-native security toolkit that leverages Trivy to continuously scan your Kubernetes cluster for security issues.

    How it works:

    1. The Operator watches the Kubernetes cluster for state changes (e.g., a new Pod being created).
    2. It automatically triggers security scans in response to these changes.
    3. Scan results are summarized in security reports as Kubernetes Custom Resource Definitions (CRDs).
    4. These reports are accessible directly through the Kubernetes API, allowing you to view risks in a Kubernetes-native way.

  4. Configure Trivy Client/Server Mode

    main

    Trivy can operate in two modes, controlled by trivy.mode:

    1. Standalone: The default mode where each scan job runs its own Trivy instance.
    2. ClientServer: A mode where a centralized Trivy server handles tasks. To use this, set operator.builtInTrivyServer: true. This overrides trivy.mode to ClientServer and sets the serverURL to the internal service address.

    When using ClientServer mode, you can configure authentication using trivy.serverToken and trivy.serverTokenHeader (defaults to Trivy-Token).

  5. Understand how built-in Configuration Audit Policies work

    main

    Trivy Operator includes built-in configuration audit policies that are automatically installed into the cluster. These policies are stored in a ConfigMap named trivy-operator-policies-config within the installation namespace (e.g., trivy-system).

    The auditing process follows these steps:

    1. The node-collector gathers infrastructure data from the node filesystem and processes.
    2. This data is output as JSON.
    3. Rego policies (sourced from the trivy-policies repository) are executed against this JSON data.
    4. The results are returned as ConfigAudit and Compliance reports.

  6. How Trivy Operator configuration auditing works

    main

    Trivy Operator provides continuous configuration auditing for Kubernetes environments. It evaluates images, workloads, and Kubernetes infrastructure components (such as Ingress, NetworkPolicy, and ResourceQuota) against security hardening standards and built-in policies.

    When violations are found, the operator generates detailed assessment reports which are stored in the default Kubernetes database. These reports can be integrated into incident response workflows for active remediation of security and compliance risks.

  7. Understand the ClusterVulnerabilityReport CRD

    main

    The ClusterVulnerabilityReport is a Custom Resource Definition (CRD) that represents the latest vulnerabilities found in Kubernetes cluster control-plane and node components. It provides a consolidated view of vulnerabilities grouped by severity and includes details for specific control-plane and node components. These reports are based on CVEs from the Kubernetes vulnerability advisory.

    Key components of the report include:

    • Summary: A count of vulnerabilities grouped by severity (e.g., criticalCount, highCount, mediumCount, lowCount, noneCount, unknownCount).
    • Artifact/OS/Registry Information: Details about the cluster environment being scanned.
    • Vulnerabilities List: An array of specific vulnerability findings, each containing:
      • vulnerabilityID: The CVE or GHSA identifier.
      • severity: The severity level (e.g., HIGH, MEDIUM, LOW).
      • resource: The specific component affected (e.g., k8s.io/kubelet, github.com/containerd/containerd).
      • fixedVersion: The version(s) where the vulnerability is resolved.
      • installedVersion: The version currently running.
      • score: The CVSS score.
      • title: A description of the vulnerability.

  8. Understand the VulnerabilityReport CRD

    main

    The VulnerabilityReport is a Custom Resource Definition (CRD) that represents the latest vulnerabilities found in a container image of a given Kubernetes workload.

    Key characteristics:

    • Scope: It includes a list of OS package and application vulnerabilities, with a summary grouped by severity.
    • Multi-container workloads: For workloads with multiple containers, trivy-operator creates multiple VulnerabilityReport instances in the workload's namespace. Each report is linked to its container via an ownerReference.
    • Naming Convention: Reports follow the pattern <workload kind>-<workload name>-<container-name> (e.g., replicaset-nginx-6d4cf56db6-nginx). Note that this naming convention may change to use image digests in future versions.
    • Integration: Any static vulnerability scanner compliant with the VulnerabilityReport schema can be integrated with trivy-operator.

  9. Understand the ClusterComplianceReport CRD structure

    main

    The ClusterComplianceReport is a Custom Resource Definition (CRD) used by the Trivy Operator to aggregate compliance scan results across a cluster. It consists of two main sections:

    1. spec.compliance: Defines the compliance standard being applied. It contains a list of controls, where each control includes one or more checks. Each check has an id, name, description, and severity.
    2. status.detailReport: Contains the actual results of the scans. It includes a results array where each entry maps a specific checkID to a target (the Kubernetes resource that failed or passed), a success boolean, and descriptive messages explaining the finding.

  10. Determine Trivy Operator Installation Mode

    main

    The installation mode (and thus the multitenancy support) is determined by the combination of OPERATOR_NAMESPACE and OPERATOR_TARGET_NAMESPACES.

    MODEOPERATOR_NAMESPACEOPERATOR_TARGET_NAMESPACESDESCRIPTION
    OwnNamespaceoperatorsoperatorsWatches events only in the namespace where the operator is deployed.
    SingleNamespaceoperatorsfooWatches events in a single specific namespace (foo) that is different from the operator's namespace.
    MultiNamespaceoperatorsfoo,bar,bazWatches events in multiple specific namespaces.
    AllNamespacesoperators(blank string)Watches events in all namespaces in the cluster.

  11. Understand the SbomReport Custom Resource Definition (CRD)

    main

    An SbomReport is a Kubernetes Custom Resource that represents the latest Software Bill of Materials (SBOM) found in a container image of a specific Kubernetes workload.

    Key Characteristics:

    • Scope: It contains a list of OS packages and application bill of materials, including a summary of components and dependencies.
    • Multi-container Workloads: For workloads with multiple containers, trivy-operator creates a separate SbomReport instance for each container.
    • Naming Convention: Reports are named using the pattern <workload kind>-<workload name>-<container-name>.
    • Ownership: Each report is created in the workload's namespace and includes an ownerReference pointing to the original workload (e.g., a Pod).

    Metadata Labels

    When inspecting an SbomReport, the following labels are used to link it back to the source resource:

    • trivy-operator.container.name: The name of the container scanned.
    • trivy-operator.resource.kind: The kind of the workload (e.g., Pod).
    • trivy-operator.resource.name: The name of the workload.
    • trivy-operator.resource.namespace: The namespace of the workload.

  12. Configure Trivy-Operator behavior and scanning

    main

    Trivy-Operator configuration is split into two distinct layers:

    1. Operator Machinery: Controlled via environment variables set on the operator Pod. Use these to tune the operator's internal lifecycle and operational settings.
    2. Scanning Behavior: Controlled via ConfigMaps and Secrets. Use these to define how Trivy performs scans, such as specifying vulnerability databases, scan intervals, or custom scanning rules.