javv-scanner¶

This chart installs the JAVV scanners in one cluster that you scan: a Trivy CronJob and a Grype CronJob.

• Each scanner pushes its own results to JAVV. JAVV never merges them.
• Install the chart in each cluster that you scan.
• JAVV itself, the javv chart, can run in that cluster or at each place that the scanners can reach over HTTP. Connect the scanners gives the full procedure.

Install¶

Prerequisites¶

• A running JAVV, and an address of JAVV that this cluster can connect to.
• An admin sign-in to JAVV.
• kubectl and Helm that can connect to this cluster, and bash.

Steps¶

1. Find the id of this cluster:

   kubectl get namespace kube-system -o jsonpath='{.metadata.uid}'
   

2. Make one ingest token for each scanner, in JAVV: Settings › Access & tokens › Mint token.
   • For the first token, select New cluster… and enter the cluster id.
   • Select the name of the scanner.
3. Put each token in its own Secret, and install the chart:

   VERSION=0.9.6
   kubectl create namespace javv-scanner
   # asks for each token, so it is not in your shell history or the process list
   for s in trivy grype; do
     read -rs -p "$s token: " token && echo
     printf '%s' "$token" | kubectl -n javv-scanner create secret generic "javv-$s-token" \
       --from-file=token=/dev/stdin
   done; unset token
   helm install scanner oci://ghcr.io/danube-labs/charts/javv-scanner --version "$VERSION" \
     -n javv-scanner \
     --set backendUrl=http://<JAVV's address>:8080 \
     --set trivy.token.existingSecret=javv-trivy-token \
     --set grype.token.existingSecret=javv-grype-token
   helm test scanner -n javv-scanner
   

   helm test verifies that JAVV replies at backendUrl and accepts each token. It does not scan.

Each scanner then runs on its schedule. To start a cycle now, follow the safe sequence in NOTES:

1. Pause the CronJob.
2. Wait until no Job of that scanner runs.
3. Make a Job from the CronJob.
4. Start the CronJob again.

Where the chart comes from¶

• Each JAVV release publishes this chart at oci://ghcr.io/danube-labs/charts, and signs it (Verify the images and charts).
• From a checkout, use the folder of the chart in deploy/helm/.

What the chart runs¶

• One CronJob for each scanner, with concurrencyPolicy: Forbid. The CronJob never starts a cycle while one of its own cycles runs. It does not count a Job that you make by hand, so use the sequence in NOTES. Kubernetes stops a cycle after activeDeadlineSeconds. The stopped cycle does not run again before the next schedule.
• A cache of the vulnerability database for each scanner: a ReadWriteOnce PersistentVolumeClaim at /var/cache/javv. Each run first refreshes the database there with the binary of the scanner, from the source of the vendor or from the source in vulnDb. Then it scans with updates off. Thus each image in a cycle gets the same database, and the scan does not connect to the vendor. Trivy uses the misconfiguration rules in its binary.
  • If the refresh fails, the run uses the database in the cache.
  • If the scanner cannot read the database, the refresh deletes it and downloads it one more time.
  • With no database that it can read, the run fails, and its log tells you why.
  • The refresh also verifies the Java database of Trivy. A damaged Java database fails no scan: Trivy only skips the jars that it cannot name.
  • Grype refuses a database older than 5 days.
• Mirrors: trivy.vulnDb.repository and trivy.vulnDb.javaRepository take OCI repositories. grype.vulnDb.updateUrl takes the address of a list of database builds. Put each other setting that the vendors read in extraEnv, for example GRYPE_DB_CA_CERT or the registry login for a private mirror.
• Kubernetes access: one ClusterRole. It can list pods, to find the running images. It can get the kube-system namespace, because its UID is the id of the cluster. It cannot read Secrets.
• Private registries: <scanner>.registryAuth.existingSecret names a kubernetes.io/dockerconfigjson Secret. Kubernetes puts its .dockerconfigjson key into the scan container as /etc/javv/registry/config.json, and DOCKER_CONFIG points the scanner at it. The refresh does not get the login. With no login, the scanner pulls each image with no sign-in, and it skips an image that it cannot pull.
• Both scanners run as the user of their images, 65532, with a read-only root file system. They have the cache volume, an emptyDir on /var/lib/javv for the dead-letter file, and an emptyDir on /tmp.

Images¶

• image.tag is the scanner version from versions.yaml in the repository. JAVV publishes that tag again when it changes the scanner image. Thus the default pullPolicy is Always.
• To run one exact build, set image.digest.
• The chart of a release sets the digest. For each scanner, it is the digest that the tag named when JAVV made the release, after cosign verified the signature of scanner-images.yml.
• A checkout of the repository has the tag only.

Values¶