Trivy Operator

Trivy Operator is an open-source security scanner that leverages Trivy to continuously scan your Kubernetes cluster for security issues.

Using Port's Kubernetes Exporter, you can keep track of all Trivy resources across your different clusters and export all the security issues to Port. You will use built in metadata from your kubernetes resources and CRDs to create entities in Port and keep track of their state.

tip

Get to know the basics of our Kubernetes exporter here!

Prerequisites

• This guide assumes you have completed the visualize your services' k8s runtime guide
• Helm must be installed to use the chart. Please refer to Helm's documentation to get started
• The jq command must installed
• The yq command must installed
• The kubectl command must be installed
• Have your Port credentials ready.

In this use-case, you will use a custom bash script which will assist you in the process of installing Port's K8s exporter.

The script will install the helm chart to the Kubernetes cluster which is currently in kubectl context. To view the context name of the cluster the exporter will be installed on, run:

kubectl config current-context

Setting up blueprints & resource mapping

The following section will guide you through the process of setting up your blueprints and resource mapping using the installation script. You can read more about the installation script here.

Creating blueprints

The installation script provides a convenient way to create your blueprints. Using the CUSTOM_BP_PATH environment variable, you can fetch a pre-defined blueprints.json to create your blueprints. For this use-case, you will use this file to define your blueprints. Do this by running:

export CUSTOM_BP_PATH="https://raw.githubusercontent.com/port-labs/template-assets/main/kubernetes/blueprints/trivy-blueprints.json"

This blueprints.json file defines the following blueprints:

• Cluster
• Namespace
• Workload
• Trivy Vulnerabilities

note

• Workload is an abstraction of Kubernetes objects which create and manage pods. By creating this blueprint, you can avoid creating a dedicated blueprint per Workload type, all of which will likely look pretty similar. Here is the list of kubernetes objects Workload will represent:

  • Deployment
  • StatefulSet
  • DaemonSet

• Trivy Vulnerabilities is one of the most important Trivy resources, giving developers the capability to find and view the risks that relate to different resources in their Kubernetes cluster.

Below is the Trivy blueprint schema used in the exporter:

Trivy vulnerability blueprint (click to expand)

{
   "identifier":"trivyVulnerabilities",
   "title":"Trivy Vulnerabilities",
   "icon":"Trivy",
   "schema":{
      "properties":{
         "scanner":{
            "title":"Scanner",
            "type":"string"
         },
         "criticalCount":{
            "title":"Critical Count",
            "type":"number"
         },
         "highCount":{
            "title":"High Count",
            "type":"number"
         },
         "lowCount":{
            "title":"Low Count",
            "type":"number"
         },
         "mediumCount":{
            "title":"Medium Count",
            "type":"number"
         },
         "category":{
            "title":"Category",
            "type":"string"
         },
         "message":{
            "title":"Message",
            "type":"array"
         },
         "severity":{
            "title":"Severity",
            "type":"string",
            "enum":[
               "LOW",
               "MEDIUM",
               "HIGH",
               "CRITICAL",
               "UNKNOWN"
            ],
            "enumColors":{
               "LOW":"green",
               "MEDIUM":"yellow",
               "HIGH":"red",
               "CRITICAL":"red",
               "UNKNOWN":"lightGray"
            }
         },
         "scannerVersion":{
            "title":"Scanner Version",
            "type":"string"
         },
         "createdAt":{
            "title":"Created At",
            "type":"string",
            "format":"date-time"
         }
      },
      "required":[]
   },
   "mirrorProperties":{},
   "calculationProperties":{},
   "aggregationProperties":{},
   "relations":{
      "namespace":{
         "title":"Namespace",
         "target":"namespace",
         "required":false,
         "many":false
      }
   }
}

Exporting custom resource mapping

Using the CONFIG_YAML_URL parameter, you can define a custom resource mapping to use when installing the exporter.

In this use-case you will be using the this configuration file. To achieve this, run:

export CONFIG_YAML_URL="https://raw.githubusercontent.com/port-labs/template-assets/main/kubernetes/templates/trivy-kubernetes_v1_config.yaml"

Below is the mapping for the Trivy resource:

Trivy vulnerability mapping (click to expand)

- kind: aquasecurity.github.io/v1alpha1/configauditreports
  port:
    entity:
      mappings:
        - identifier: .metadata.name + "-" + .metadata.namespace + "-" + env.CLUSTER_NAME
          title: .metadata.name
          icon: '"Trivy"'
          blueprint: '"trivyVulnerabilities"'
          properties:
            scanner: .report.scanner.name
            criticalCount: .report.summary.criticalCount
            highCount: .report.summary.highCount
            lowCount: .report.summary.lowCount
            mediumCount: .report.summary.mediumCount
            category: .report.checks[0].category
            message: .report.checks[0].messages
            severity: .report.checks[0].severity
            scannerVersion: .report.scanner.version
            createdAt: .metadata.creationTimestamp
          relations:
            namespace: .metadata.namespace + "-" + env.CLUSTER_NAME

Alternative integration using script

While the Trivy Kubernetes exporter described above is the recommended installation method, you may prefer to use a webhook and a script to ingest your Trivy scan results to Port.