Configuring FOSSA's Helm values

Now that we have Helm set up and configured FOSSA's Helm chart repository, we need to create a Helm values file in preparation for installing FOSSA as a Helm release.

Getting your initial values

To start, you should use one of our provided of initial values files:

(recommended) simplified.values.yaml: if you're using managed external hosting for FOSSA's service dependencies, we recommend using this configuration file. It uses YAML anchors and references to provide simplified controls for common configuration tasks.
simplified.self-hosted.values.yaml: if you want FOSSA to self-host its service dependencies, we recommend using this configuration file. It uses YAML anchors and references to provide simplified controls for common configuration tasks.
advanced.values.yaml: this file does not use YAML anchors at all, and directly exposes the initial chart configuration to users. If you choose to use this file, make sure to reference the documentation in the chart's values.yaml.

Regardless of which initial set you pick, all of these configure the same values file using the same schema. The simplified files only use YAML anchors and references to make configuration more convenient.

You can always find the documentation for a particular value by inspecting the chart and examining values.yaml.

Common value customizations

Now that you have your initial set of values, we'll customize these values to your specific installation.

While you're making changes to your values, you can see the resulting rendered values using:

# helm template RELEASE_NAME CHART_NAME [FLAGS]
$ helm template fossa fossa/fossa-core --values YOUR_VALUES_FILE.yaml

This will fully render the resulting YAML file, including resolving anchors and references. To see what these values do, compare them against the values.yaml file in the fossa/fossa-core chart.

Basic configuration

The first thing you'll need to configure are the basics:

FOSSA image credentials
The application encryption secret
Hostname and port

FOSSA image credentials

To configure FOSSA image credentials, set global.imageCredentials.username and global.imageCredentials.password. You should get the values for these fields from your account manager.

Application encryption secret

Set encryptionSecret to a random 64-character hexadecimal string. This secret is used to encode application-level secrets such as API keys for accessing VCS repositories.

You generally should not need to change this secret over time. If you change this secret, you may need to reconfigure all application-level credentials.

Hostname and port

Set hostname to a string hostname and port to an integer port.

The hostname you pick must be accessible to your end users. Later, you'll configure a DNS entry for this hostname so that users can access FOSSA.

Configuring external services

Next, we'll set up external services:

Database
Object storage
Email server

The field names referenced here are all for the Simplified charts. To use the advanced chart, reference the comments in the chart's fields.

Database

For databases using managed external hosting, you'll need to tell FOSSA how to connect to the database. You'll need to set:

postgres.host
postgres.username
postgres.password
postgres.database (this is the dbname that you'd like FOSSA to use in your Postgres server)

For databases using self-hosting, FOSSA will create a self-hosted Postgres instance for you. Instead, you only need to set the username and password of the database user to be created:

postgresAuth.username
postgresAuth.password

S3-compatible object storage

For object storage using managed external hosting, you'll need to tell FOSSA how to connect to S3. You'll need to set:

storageCoreBucket
storageHubbleBucket
storageEndpoint
storageRegion
storageAuth.accessKey
storageAuth.secretKey

For object storage using self-hosting, FOSSA will create self-hosted MinIO instances for you. However, the object storage for the FOSSA web application must be accessible to end users because we use CORS to directly upload and download files from object storage.

This means you'll need to set storageHostname to a user-accessible hostname. Later, we will also configure a DNS entry for this hostname. If you are using managed external hosting, you do not need to set this hostname (because we use the S3 endpoint instead).

Email server

All FOSSA installations use an external email server. You'll need to configure:

email.from
email.host
email.port
email.auth.user
email.auth.password

Make sure that FOSSA can access the SMTP server you configured it to use.

Terminating SSL

If you are hosting FOSSA behind HTTPS, you can configure its Kubernetes Ingress to terminate SSL:

If your Ingress Controller supports automation for HTTPS certificates via annotations, you can use ingressAnnotations to set annotations on the FOSSA web application's Ingress.
If you intend to manually configure your TLS certificates, you can use ingressTLS to set the tls field of the FOSSA web application's Ingress. You will need to manually construct the corresponding Secret containing the TLS certificate's contents.

Trusting self-signed certificates

If you are using self-signed certificates in your network, FOSSA will need to be configured to trust those self-signed certificates.

To do this, set the trustedCertificates field. The value of this field should be a map where the key name is the hash of the certificate with .0 appended, and the value is the certificate's contents itself. You can generate the hash of a certificate using openssl x509 -noout -hash -in certificate.pem.

For example:

trustedCertificates:
  5a7a72df.0: |-
    -----BEGIN CERTIFICATE-----
    MIIFATCCAumgAwIBAgIRAKc9ZKBASymy5TLOEp57N98wDQYJKoZIhvcNAQELBQAw
    ...
    8iyIYUyQAbsvx8oD2M8kRvrIRSrRJSl6L957b4AFiLIQ/GgV2curs0jje7Edx34c
    idWw1VrejtwclobqNMVtG3EiPUIpJGpbMcJgbiLSmKkrvQtGng==
    -----END CERTIFICATE-----