Configuring FOSSA's Helm values
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:
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
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
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
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.password. You should get the values for these fields from your account manager.
Application encryption secret
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
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:
- 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.
For databases using managed external hosting, you'll need to tell FOSSA how to connect to the database. You'll need to set:
postgres.database(this is the
dbnamethat 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:
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:
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).
All FOSSA installations use an external email server. You'll need to configure:
Make sure that FOSSA can access the SMTP server you configured it to use.
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
ingressAnnotationsto set annotations on the FOSSA web application's
- If you intend to manually configure your TLS certificates, you can use
ingressTLSto set the
tlsfield of the FOSSA web application's
Ingress. You will need to manually construct the corresponding
Secretcontaining 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.
trustedCertificates: 5a7a72df.0: |- -----BEGIN CERTIFICATE----- MIIFATCCAumgAwIBAgIRAKc9ZKBASymy5TLOEp57N98wDQYJKoZIhvcNAQELBQAw ... 8iyIYUyQAbsvx8oD2M8kRvrIRSrRJSl6L957b4AFiLIQ/GgV2curs0jje7Edx34c idWw1VrejtwclobqNMVtG3EiPUIpJGpbMcJgbiLSmKkrvQtGng== -----END CERTIFICATE-----
Updated about 22 hours ago