What steps did you take and what happened:

I am using the latest version of the trivy-operator go module to transform different CRDs in a unified format. While working with the ClusterComplianceDetailReports Informer I have the issue that the Objects in the Informer Callbacks are *v1alpha1.ClusterComplianceReport.

What did you expect to happen:

Expected to get *v1alpha1.ClusterComplianceDetailReport objects from the ClusterComplianceDetailReports Informer.

Anything else you would like to add:

Code Snippet I am using:

import (
	"github.com/aquasecurity/trivy-operator/pkg/apis/aquasecurity/v1alpha1"
	"github.com/aquasecurity/trivy-operator/pkg/generated/clientset/versioned"
	"github.com/aquasecurity/trivy-operator/pkg/generated/informers/externalversions"
	corev1 "k8s.io/api/core/v1"
)

client, _ := versioned.NewForConfig(k8sConfig)

factory := externalversions.NewFilteredSharedInformerFactory(client, 0, corev1.NamespaceAll, nil)

informer := factory.Aquasecurity().V1alpha1().ClusterComplianceDetailReports().Informer()
informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
	AddFunc: func(obj interface{}) {
		fmt.Printf("%T\n", obj)
	},
})

informer.Run(ctx.Done())

Output:

*v1alpha1.ClusterComplianceReport

Environment:

• Trivy-Operator version (use trivy-operator version): 0.0.3
• Kubernetes version (use kubectl version): v1.22.3
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): macOS

Add a Web UI that makes it easy to consume the CRD that the operator generates

Trivy now has support to secrets scanning. We should upgrade it, and make sure secrets are supported.

What steps did you take and what happened:

I followed the installation step

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/trivy-operator/v0.0.3/deploy/static/trivy-operator.yaml

And I see 2 CM being created. It also seems the trivyoperator-trivy-config is overriding the config.

% kubectl get cm -n trivy-system
NAME                             DATA   AGE
...
trivy-operator-trivy-config      9      8m28s
trivyoperator-trivy-config       9      58s

BTW trivyoperator-trivy-config gets regenerated even after delete

[A clear and concise description of what the bug is, and what commands you ran.]

What did you expect to happen:

See only 1 cm

Anything else you would like to add:

[Miscellaneous information that will assist in solving the issue.]

Environment:

• Trivy-Operator version (use trivy-operator version): 0.0.3
• Kubernetes version (use kubectl version): 1.21
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): Photon

What steps did you take and what happened:

Tried out trivy-operator 0.0.7 today and installed it on my test cluster (k8s 1.23.6) via Helm. After the operator started it immediately began to run dozens of Jobs which quickly overwhelmed the cluster with very high CPU and memory consumption to the point where the whole cluster became unresponsive. Many of the Job pods got OOM killed.

What did you expect to happen:

Minimal impact of normal operation on the cluster. Basically, I expect trivy-operator to run things neatly in the background.

Anything else you would like to add:

I feel like I need an easy way to limit the number of concurrent Jobs the operator is allowed to run. I haven't found a corresponding parameter, yet. Not sure, if I have to start working with Resource Quotas somehow.

Or do you recommend to run trivy in ClientServer mode to limit resource usage?

Environment:

• Trivy-Operator version (use trivy-operator version): 0.0.7
• Kubernetes version (use kubectl version): 1.23.6
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): Debian 5.10.92-1

Helm values:
trivy:
ignoreUnfixed: true

I suspect that the operator is scanning images based on the workload specification. This might not always be accurate, and I think it would be better if the scanning was based on the actual image the Pod container is running on.

We have developed an in-house operator similar to trivy-operator, but would like to abandon this work and put our effort into the trivy-operator instead. There might be several ways to fix this issue, but in our operator we watch pods (filtering events) instead of the workload. That allows us to pull out the actual running container image digest from the Pod containerStatuses, and that will always give accurate results.

Possibly related issue: #101

Since we've added multi arch support, we started getting timeout errors while publishing container images to Amazon ECR Public Gallery.

goreleaser_publish_to_ecr

To unblock the release workflow, we temporarily stopped publishing to ECR, but we must bring this functionality back. One idea is to create a dedicated workflow that's scheduled after the main release workflow that will pull images from DockerHub, tag them, and publish them to ECR. We should also have an option to dispatch this workflow manually with Git revision as param.

make sure trivy is scanning and reporting on init/ephemeral container

The configaudit reports are namespaced, and they are created for several resources, we should have a plural for it. Currently it only supports singular:

configauditreports                configaudit                    aquasecurity.github.io/v1alpha1        true         ConfigAuditReport

create a trivy-operator Lens extension (based on Starboard's https://github.com/aquasecurity/starboard-lens-extension)

thanks for @nublarsec for raising this in Slack https://aquasecurity.slack.com/archives/C02KSDSBPGD/p1654184354851129

The motivation for this task is to eat aqua open source dog food, meaning have a unified kubernetes policy scanner lib used in the builtin config audit scanner (same as used in other projects).

In this task, trivy-operator will incorporate the new Kubernetes policy scanner introduced by Defsec and it will replace the embedded policy lib used to evaluate configAudit rego scripts.

here is the reference to the new scanner : https://github.com/aquasecurity/defsec/tree/master/pkg/scanners/kubernetes

What steps did you take and what happened:

I installed the trivy-operator via kubectl in version 0.0.5 and made the necessary changes to pull all images from our internal registry (JFrog Artifactory). The operator is running fine and starts the scanning pods. Except for the changes to the image sources, the operator is running with the default config.

However, the logs show the following error: failed to download vulnerability DB: OCI artifact error: OCI artifact error: OCI repository error: Get \"https://packages.repo.internal.com/v2/\": x509: certificate signed by unknown authority\n"

This repository uses a self-signed certificate, so this error is expected.

In the documentation I found a parameter to set registries to unsecure: trivy.insecureRegistry.

So I added this to the trivy-operator-trivy-config configmap:

data:  
  trivy.insecureRegistry.artifactory: "packages.repo.internal.com"

This seems to have no effect, the error is unchanged.

What did you expect to happen:

I would expect trivy to skip the certificate validation with this setting.

Anything else you would like to add:

Environment:

• Trivy-Operator version (use trivy-operator version): 0.0.5
• Kubernetes version (use kubectl version): v1.22.6
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): Ubuntu 20.04

Added support for scanning the private registry of AWS-ECR.
When passing to Trivy Scan job it has no Region based on the scanned ECR-URL.

This PR will add the environment variable which will be passed and later used by trivy to make the right call to AWS.

What are the plans for adding back CIS Benchmark support into the trivy-operator (which existed in Starboard using kube-bench)?

Are there any plans for SBOM report generation in the future?

It is required to remove the aqua scanner plugin

• plugin logic
• controller
• helm chart

Hello,

With Trivy-Operator v0.0.3, when I use httproxy or alternative dbrepository from helm values, they are ignored as I see on operator logs which is expected without proxy.

1.654187065028448e+09   ERROR   reconciler.vulnerabilityreport  Scan job container  {"job": "trivy-operator/scan-vulnerabilityreport-75f4d75dc", "container": "de973285-8e3f-485d-aed4-5dfd7ee210fb", "status.reason": "Error", "status.message": "2022-06-02T16:24:21.651Z\t\u001b[34mINFO\u001b[0m\tNeed to update DB\n2022-06-02T16:24:21.651Z\t\u001b[34mINFO\u001b[0m\tDB Repository: ghcr.io/aquasecurity/trivy-db\n2022-06-02T16:24:21.651Z\t\u001b[34mINFO\u001b[0m\tDownloading DB...\n2022-06-02T16:24:21.659Z\t\u001b[31mFATAL\u001b[0m\tDB error: failed to download vulnerability DB: OCI artifact error: OCI artifact error: OCI repository error: Get \"https://ghcr.io/v2/\": dial tcp: lookup ghcr.io on 172.16.0.1:53: no such host\n"}

Helm values helm get values -n ns-trivy ns-trivy

image:
  pullSecrets:
  - name: myregistry
  repository: myregistry.lan/aquasec/trivy-operator
operator:
  logDevMode: true
trivy:
  dbRepository: myregistry.lan/aquasecurity/trivy-db
  httpProxy: http://proxy.mydomain.lan:3128
  httpsProxy: http://proxy.mydomain.lan:3128
  noProxy: myregistry.lan
  ignoreUnfixed: false

On CM side, trivy-operator-trivy-config contains what I defined on helm side

kind: ConfigMap
apiVersion: v1
metadata:
  name: trivy-operator-trivy-config
  namespace: ns-trivy
  labels:
    app.kubernetes.io/instance: ns-trivy
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trivy-operator
    app.kubernetes.io/version: 0.0.3
    helm.sh/chart: trivy-operator-0.0.3
  annotations:
    meta.helm.sh/release-name: ns-trivy
    meta.helm.sh/release-namespace: ns-trivy
data:
  trivy.mode: Standalone
  trivy.timeout: 5m0s
  trivy.resources.requests.memory: 100M
  trivy.httpsProxy: 'http://proxy.mydomain.lan:3128'
  trivy.httpProxy: 'http://proxy.mydomain.lan:3128'
  trivy.resources.requests.cpu: 100m
  trivy.dbRepository: myregistry.lan/aquasecurity/trivy-db
  trivy.noProxy: myregistry.lan
  trivy.resources.limits.memory: 500M
  trivy.imageRef: 'docker.io/aquasec/trivy:0.25.2'
  trivy.resources.limits.cpu: 500m
  trivy.severity: 'UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL'

But containers named scan-vulnerabilityreport-xxx contains

    initContainers:
    - args:
      - --cache-dir
      - /tmp/trivy/.cache
      - image
      - --download-db-only
      - --db-repository
      - ghcr.io/aquasecurity/trivy-db
      command:
      - trivy
      env:
      - name: HTTP_PROXY
        valueFrom:
          configMapKeyRef:
            key: trivy.httpProxy
            name: trivyoperator-trivy-config
            optional: true

Note the CM name without dash trivyoperator-trivy-config

This CM doesn't contains my overrides

kind: ConfigMap
apiVersion: v1
metadata:
  name: trivyoperator-trivy-config
  namespace: ns-trivy
data:
  trivy.timeout: 5m0s
  trivy.resources.requests.memory: 100M
  trivy.mode: Standalone
  trivy.resources.requests.cpu: 100m
  trivy.dbRepository: ghcr.io/aquasecurity/trivy-db
  trivy.resources.limits.memory: 500M
  trivy.imageRef: 'docker.io/aquasec/trivy:0.25.2'
  trivy.resources.limits.cpu: 500m
  trivy.severity: 'UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL'

They are quite similar and looks like a bug as on code side I could found both names.

If it's expected, I don't get it, how I could set thoses values and what are differences ?

Also when I uninstall the cm without dash is not removed.

It is required to remove the conf-test plugin

• plugin logic
• controller
• helm chart

The CRD ClusterVulnerabilityReport is installed when using helm but not by the static kubectl apply -f.
Which one is correct?

helm install

$ kubectl api-resources | grep aqua | grep vuln
clustervulnerabilityreports       clustervuln,clustervulns   aquasecurity.github.io/v1alpha1        false        ClusterVulnerabilityReport
vulnerabilityreports              vuln,vulns                 aquasecurity.github.io/v1alpha1        true         VulnerabilityReport

kubectl apply -f

$ kubectl api-resources | grep aqua | grep vuln
vulnerabilityreports              vuln,vulns           aquasecurity.github.io/v1alpha1        true         VulnerabilityReport

What steps did you take and what happened:

I'm trying to get starboard to scan images in a private GCR registry, and I've successfully created the secrets and service account associations with the credentials.

To confirm my credentials work, I used:

cat gcp-starboard-key.json | docker login -u _json_key --password-stdin https://gcr.io/

With gcp-starboard-key.json being GCP service account credentials.

I then created the docker-registry secret in kubernetes using this command:

kubectl create secret docker-registry starboard-gcp-access --namespace default --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/Downloads/gcp-starboard-key.json)" --docker-email="[email protected]"

I associated the secret with the service accounts by adding the imagePullSecret: starboard-gcp-access.

In the starboard-operator logs, I see this:

"error":"reading .dockerconfigjson field of \"default/starboard-gcp-access\" secret: expected username and password concatenated with a colon (:)","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227"}

What did you expect to happen:

Starboard to pull the image and scan for VulnerabilityReport

Anything else you would like to add:

The cluster is running the latest version of GKE Autopilot (1.22.6).

Environment:

• Starboard Version: {Version:0.14.1 Commit:5672fd4a4d608d9b094802098f3e950ec396ff51 Date:2022-01-25T17:38:43Z}
• Kubernetes version (use kubectl version): Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-16T15:51:05Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"darwin/arm64"} Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.6-gke.300", GitCommit:"df413ee6225aa3fc539e18ca3464a48d723bd3ea", GitTreeState:"clean", BuildDate:"2022-01-24T09:29:08Z", GoVersion:"go1.16.12b7", Compiler:"gc", Platform:"linux/amd64"}
• macOS 10.15

Add support for integration with postee :

• support configuration setting for postee
• add capability to wire reports via postee
• add capability to filter reports data passed to postee

Using private registry, ex xxx.jfrog.io
The secret used to pull images from this repos is formated as below

.dockerconfigjson: '{"auths": {"*.jfrog.io": {"username":"mylogin","password":"xxx","email":"foo@bar"}}}'

When starboard launch the Job to scan the pod, there is not secret created, and the scan fail with this error

{"level":"error","ts":1654176088.1880994,"logger":"reconciler.vulnerabilityreport","msg":"Scan job container","job":"xxx-system/scan-vulnerabilityreport-f954d8cf","container":"xxx","status.reason":"Error","status.message":"2022-06-02T13:21:27.538Z\t\u001b[31mFATAL\u001b[0m\tscan error: unable to initialize a scanner: unable to initialize the docker scanner: 3 errors occurred:\n\t* unable to inspect the image (demo-api.jfrog.io/apidemo:v0.1): Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?\n\t* unable to initialize Podman client: no podman socket found: stat podman/podman.sock: no such file or directory\n\t* GET https://demo-api.jfrog.io/v2/apidemo/manifests/v0.1: UNAUTHORIZED: The client does not have permission for manifest; map[manifest...

If a change the wildcard by the complete registry hostname ex : demo-api.jfrog.io, all works fine.

What did you expect to happen:

As docker, starboard should find the most similar host inside the imagePullSecret to try to pull image. and therefore work with wildcards expression.

Maybe to change exacte comparaison to regexp match there :

The the mapping from a container name to the Docker authentication credentials for the specified kube.ContainerImages and image pull Secrets can use wildcard or other regexp.

I'm not a Go developer, it's just a guess :D

Environment:

• version :0.0.7
• Kubernetes version : 1.21
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): N/A

fix main docs broken links

Perhaps we should not apply the CRDs for compliance on the cluster while we are not supporting it. It might be misleading.

When we install trivy-operator via helm or kubectl the configmaps are using the name trivy-operator, but the code is looking for trivyoperator, as it doesn't exist, the plugin will create the configmap leading to a duplication:

It is required to remove the kube-hunter plugin

• plugin logic
• controller
• helm chart
• crds

This was reported by @erikgb on slack. It seems configaudit report has entries duplicated.

kubectl get -o yaml configaudits replicaset-lala-5b9f4c6796 | grep checkID | sort
    checkID: KSV001
    checkID: KSV001
    checkID: KSV002
    checkID: KSV002
    checkID: KSV003
    checkID: KSV003
    checkID: KSV004
    checkID: KSV004
    checkID: KSV005
    checkID: KSV005
    checkID: KSV006
    checkID: KSV006
    checkID: KSV007
    checkID: KSV007
    checkID: KSV008
    checkID: KSV008
    checkID: KSV009
    checkID: KSV009
    checkID: KSV010
    checkID: KSV010
    checkID: KSV011
    checkID: KSV011
    checkID: KSV012
    checkID: KSV012
    checkID: KSV013
    checkID: KSV013
    checkID: KSV014
    checkID: KSV014
    checkID: KSV015
    checkID: KSV015
    checkID: KSV016
    checkID: KSV016
    checkID: KSV017
    checkID: KSV017
    checkID: KSV018
    checkID: KSV018
    checkID: KSV020
    checkID: KSV020
    checkID: KSV021
    checkID: KSV021
    checkID: KSV022
    checkID: KSV022
    checkID: KSV023
    checkID: KSV023
    checkID: KSV024
    checkID: KSV024
    checkID: KSV025
    checkID: KSV025
    checkID: KSV026
    checkID: KSV026
    checkID: KSV027
    checkID: KSV027
    checkID: KSV028
    checkID: KSV028
    checkID: KSV029
    checkID: KSV029
    checkID: KSV030
    checkID: KSV030
    checkID: KSV032
    checkID: KSV032
    checkID: KSV033
    checkID: KSV033
    checkID: KSV036
    checkID: KSV036
    checkID: KSV037
    checkID: KSV037
    checkID: KSV102
    checkID: KSV102

What steps did you take and what happened:

• I deployed the trivy-operator helm chart using an ArgoCD application and noticed a small issue.
  The trivy operator get's installed and it's working perfectly, but the trivy-operator CRDs are staying out-of-sync in ArgoCD.
  This is because the categories: field of all trivy-operator CRD is an empty list and get's dropped by Kubernetes.
  While this might not be an issue for trivy-operator and kubernetes, it is for argocd that sees a diff between the desired state and the live state.

What did you expect to happen:

• I expect to have all trivy-operator CRD in sync after the helm chart deployment.

Anything else you would like to add:

• Coming back with a PR to fix

[Miscellaneous information that will assist in solving the issue.]

Environment:

• Trivy-operator version (use trivy-operator version): v0.0.3
• Kubernetes version (use kubectl version): v1.20.15-eks (aws eks)
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): archlinux

Let's change the github issue template to have features created as issues, instead of discussion.

We should display the vulnerability target. For example, when scanning an image with golang binaries, that will be a target per binary:

usr/bin/prometheus (gobinary)

Total: 2 (UNKNOWN: 2, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

┌──────────────────────────────────────┬─────────────────────┬──────────┬──────────────────────────────────────┬───────────────┬───────────────────────────────────────────────────┐
│               Library                │    Vulnerability    │ Severity │          Installed Version           │ Fixed Version │                       Title                       │
├──────────────────────────────────────┼─────────────────────┼──────────┼──────────────────────────────────────┼───────────────┼───────────────────────────────────────────────────┤
│ github.com/docker/distribution       │ GHSA-qq97-vm5h-rrhg │ UNKNOWN  │ v2.7.1+incompatible                  │ v2.8.0        │ OCI Manifest Type Confusion Issue                 │
│                                      │                     │          │                                      │               │ https://github.com/advisories/GHSA-qq97-vm5h-rrhg │
├──────────────────────────────────────┼─────────────────────┤          ├──────────────────────────────────────┼───────────────┼───────────────────────────────────────────────────┤
│ github.com/opencontainers/image-spec │ GHSA-77vh-xpmg-72qh │          │ v1.0.2-0.20211117181255-693428a734f5 │ 1.0.2         │ Clarify `mediaType` handling                      │
│                                      │                     │          │                                      │               │ https://github.com/advisories/GHSA-77vh-xpmg-72qh │
└──────────────────────────────────────┴─────────────────────┴──────────┴──────────────────────────────────────┴───────────────┴───────────────────────────────────────────────────┘

usr/bin/promtool (gobinary)

Total: 2 (UNKNOWN: 2, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

┌──────────────────────────────────────┬─────────────────────┬──────────┬──────────────────────────────────────┬───────────────┬───────────────────────────────────────────────────┐
│               Library                │    Vulnerability    │ Severity │          Installed Version           │ Fixed Version │                       Title                       │
├──────────────────────────────────────┼─────────────────────┼──────────┼──────────────────────────────────────┼───────────────┼───────────────────────────────────────────────────┤
│ github.com/docker/distribution       │ GHSA-qq97-vm5h-rrhg │ UNKNOWN  │ v2.7.1+incompatible                  │ v2.8.0        │ OCI Manifest Type Confusion Issue                 │
│                                      │                     │          │                                      │               │ https://github.com/advisories/GHSA-qq97-vm5h-rrhg │
├──────────────────────────────────────┼─────────────────────┤          ├──────────────────────────────────────┼───────────────┼───────────────────────────────────────────────────┤
│ github.com/opencontainers/image-spec │ GHSA-77vh-xpmg-72qh │          │ v1.0.2-0.20211117181255-693428a734f5 │ 1.0.2         │ Clarify `mediaType` handling                      │
│                                      │                     │          │                                      │               │ https://github.com/advisories/GHSA-77vh-xpmg-72qh │
└──────────────────────────────────────┴─────────────────────┴──────────┴──────────────────────────────────────┴───────────────┴───────────────────────────────────────────────────┘

Currently, our report only shows them as vulnerabilities:

Title:              Clarify `mediaType` handling
Vulnerability ID:   GHSA-77vh-xpmg-72qh
Fixed Version:      v2.8.0
Installed Version:  v2.7.1+incompatible
Links:
Primary Link:       https://github.com/advisories/GHSA-qq97-vm5h-rrhg
Resource:           github.com/docker/distribution
Severity:           UNKNOWN

Title:              OCI Manifest Type Confusion Issue
Vulnerability ID:   GHSA-qq97-vm5h-rrhg
Fixed Version:      1.0.2
Installed Version:  v1.0.2-0.20211117181255-693428a734f5
Links:
Primary Link:      https://github.com/advisories/GHSA-77vh-xpmg-72qh
Resource:          github.com/opencontainers/image-spec
Severity:          UNKNOWN
Title:             Clarify `mediaType` handling
Vulnerability ID:  GHSA-77vh-xpmg-72qh

Trivy fs scanning in the same namespace does not work with the latest starboard. release. v0.15.4.
getting this error:

{"level":"error","ts":1651479039.0873706,"logger":"reconciler.vulnerabilityreport","msg":"Scan job container","job":"test-file/scan-vulnerabilityreport-dfcd666f8","container":"6ed20c40-482d-444b-b4b9-968439d67ee4","status.reason":"Error","s
tatus.message":"2022-05-02T08:10:09.436Z\t\u001b[34mINFO\u001b[0m\tNeed to update DB\n2022-05-02T08:10:09.436Z\t\u001b[34mINFO\u001b[0m\tDownloading DB...\n2022-05-02T08:10:38.658Z\t\u001b[31mFATAL\u001b[0m\tDB error: failed to download vulnerability DB: OCI artifact error: OCI artifact error: OCI repository error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: i/o timeout\n","stacktrace":"github.com/aquasecurity/starboard/pkg/vulnerabilityreport.(*WorkloadController).reconcileJobs.func1\n\t/Users/test.file/Documents/GitHub/starboard/pkg/vulnerabilityreport/controller.go:32

update trivy-operator-trivy-config configmap :
trivy.command: filesystem

Expected result :
scan image

Actual result:
fail with error

It's technically possible to scan private registries if we have a way to pass
TRIVY_INSECURE
TRIVY_USERNAME
TRIVY_PASSWORD
variables to the trivy scanner.
We could set up TRIVY_INSECURE parameter via env.
And we could get TRIVY_USERNAME&TRIVY_PASSWORD from k8s secret with registry pull rights (or any other way).

Add Trivy-Operator to Operator hub

Are we able to push a new release soon? I use FluxCD to provision the operator, and would really like to see a release containing this unblocking bugfix: #42. The workaround renaming the ConfigMap does not work very well with a GitOps controller as Flux.

expose operational metrics that reflects the health and status of the operator

It would be nice to have a way to set up securityContexts for:

• initContainers
• jobs, which are being run during scans. Including compliance scan jobs, which require a lot of host-level access.

Reached out via Twitter and was redirected here.

From my understanding, the operator is pulling container images based on the image path it scrapes from live objects on the cluster. However, it's pulling them directly, bypassing configuration on the host. Personally, I'd like the option to utilize the CRI on the actual host so that we can be sure the image that gets pulled actually matches what's running for real.

To cite a specific example, the clusters I manage are running CRI-O, and utilize the registry mirror functionality to do rewrites of the image pulls live. This allows us to attempt to pull from a cluster-local image cache first, with fallback to our canonical registry if that fails. Additionally, we use the rewrites to ensure that a pull from something like Docker Hub is forcefully redirected to pull through our canonical registry so we can cache and scan images. By having Trivy respect the behavior of the node it runs on, we can better ensure that the images it scans are accurately pulled.

eg: https://github.com/aquasecurity/trivy/blob/main/misc/triage/labels.yaml

it is required to remove the kube-bench plugin

• plugin logic
• controller
• helm chart
• crds

Add rbac scanning support :

• extend config audit scanning conmfigmap to include rbac policies
• represent rnac result in a designated report

create a prometheus exporter that exposes the results or trivy-operator as prometheus metrics.
For example, vulnerabilities as metrics.

TBD: spec how results map to metrics and labels

The scanner should be Trivy:

Add a Link to Trivy Project --> Operator section (https://aquasecurity.github.io/trivy/latest/docs/kubernetes/operator/)
on the main README file

In order to support latest features on trivy (like secret scanning) let's update the version.

What steps did you take and what happened:

1. I have a question.
2. I read the contributing guidelines that tell me to create a discussion in the Discussions tab.
3. I could not find the Discussions tab.
4. I opted for a new issue. I got to choose between "Bug report", "Feature request", and "Ask a question". The button for "Ask a question" opened the page https://github.com/aquasecurity/trivy-operator/discussions/new?category_id=18526498 which could not be found.

🙂

it is required to deprecate the octant

• update docs
• update diagrams

Add mkdoc to Trivy-operator.
can be moved from here trivy-->operator

Remove the polaris plugin :

• plugin logic
• controller
• helm chart