This is unreleased documentation for SBOM Scanner 0.13-dev.

Helm Values Configuration

This document describes the available configuration options for the SBOM Scanner Helm chart.

Configure these values in one of these ways:

Create a values file, for example my-values.yaml. Add your overrides and pass the file to Helm:

helm install sbomscanner ./chart -f my-values.yaml

Use --set flags to override specific values directly:

helm install sbomscanner ./chart --set controller.replicas=5 --set storage.postgres.cnpg.instances=5

For more details on customizing Helm charts, see the Helm documentation.

Log Levels

Configure the log level for each SBOM Scanner component. The log level controls log detail.

controller:
  logLevel: "info"

storage:
  logLevel: "info"

worker:
  logLevel: "info"

Available log levels are: debug, info, warn, error.

Resource Limits and Requests

Each component has default resource limits and requests. Configure these values for your cluster capacity and workload requirements.

Controller

controller:
  resources:
    limits:
      cpu: 500m
      memory: 2Gi
    requests:
      cpu: 250m
      memory: 300Mi

Storage

storage:
  resources:
    limits:
      cpu: 500m
      memory: 3Gi
    requests:
      cpu: 250m
      memory: 300Mi

Worker

worker:
  resources:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 250m
      memory: 300Mi

Adjust these values based on your workload. The storage component typically needs more memory due to SBOM processing.

For more information on resource management, see the Kubernetes documentation on resource requests and limits.

PostgreSQL Configuration

SBOM Scanner requires a PostgreSQL database to store SBOM data. You have two options: use the built-in CloudNativePG (CNPG) operator or connect to an external PostgreSQL instance.

Using CloudNativePG (Recommended)

By default, SBOM Scanner deploys a PostgreSQL cluster using the CloudNativePG operator. This is the easiest way to get started.

storage:
  postgres:
    cnpg:
      enabled: true
      instances: 3
      imageName: ""
      storage:
        size: 1Gi
        resizeInUseVolumes: true
        storageClass: ""
        pvcTemplate: {}

Configuration options:

instances: Number of PostgreSQL replicas (default: 3)
imageName: Full image reference for the PostgreSQL container, for example my-registry.example.com/postgresql:18.1. Use this value when the default CNPG operand image is unavailable. If empty, CNPG uses its default operand image.
storage.size: Size of the persistent volume. You can increase this value later. CNPG applies the change to existing PVCs. You cannot decrease this value. See the CNPG documentation.
storage.resizeInUseVolumes: Automatically resize PVCs (default: true)
storage.storageClass: Specify a storage class. If empty, uses the cluster’s default storage class.
storage.pvcTemplate: Custom PVC template if you need advanced configuration

For more configuration options, refer to the CloudNativePG Cluster configuration documentation.

Using an External PostgreSQL Instance

If you already have a PostgreSQL instance or prefer to manage it separately, disable CNPG and provide connection details.

storage:
  postgres:
    cnpg:
      enabled: false
    authSecretName: "my-postgres-credentials"
    caSecretName: "my-postgres-ca"

Steps to configure external PostgreSQL:

Create a Secret with the PostgreSQL connection URI:

apiVersion: v1
kind: Secret
metadata:
  name: my-postgres-credentials
  namespace: default
stringData:
  uri: "postgresql://user:password@postgres.example.com:5432/sbomscanner?sslmode=require"

The URI format follows the PostgreSQL connection URI specification.

Any sslmode or other ssl* parameters in the URI are ignored.
SBOM Scanner always enforces CA verification when connecting to the database,
using the CA certificate specified in the caSecretName secret.

Create a Secret with the CA certificate used to verify the PostgreSQL server certificate:

apiVersion: v1
kind: Secret
metadata:
  name: my-postgres-ca
  namespace: default
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Reference the secrets in your Helm values:

storage:
  postgres:
    authSecretName: "my-postgres-credentials"
    caSecretName: "my-postgres-ca"

When you use an external PostgreSQL instance, make sure that the database exists and is accessible from your Kubernetes cluster.

Default VEXHub Resources

When you install the chart, SBOM Scanner seeds two VEXHub resources. They point to the public github.com/rancher/vexhub and github.com/aquasecurity/vexhub repositories. A post-install hook creates these resources. Helm does not track them. You can modify, disable, or delete them. Helm does not revert these changes during upgrades.

controller:
  defaultVEXHubResources: true

Set this to false to prevent default-resource seeding. Use this setting in air-gapped environments. See Air Gap Support to configure a self-hosted VEX Hub.

OpenTelemetry

Three values configure the telemetry export. Telemetry export is off when otel.endpoint is empty.

otel:
  endpoint: "https://otel-collector.telemetry.svc.cluster.local:4317"
  caSecretName: "sbomscanner-otel-client"
  clientCertificateSecretName: "sbomscanner-otel-client"

otel.endpoint is the OTLP/gRPC endpoint that receives the telemetry. Using a https:// URL makes the components connect with TLS.
otel.caSecretName names a secret with a ca.crt key. The components use this CA certificate to verify the server’s endpoint certificate.
otel.clientCertificateSecretName names a secret with tls.crt and tls.key keys. The components use this certificate to authenticate to the endpoint (mTLS).

Both secrets must exist in the namespace where SBOM Scanner is installed. See OpenTelemetry for the full setup and OpenTelemetry Reference for the exported traces and metrics.