Installation in a Kubernetes cluster¶

Compatible software versions¶

Recommended Software	Recommended Software version	Alternative Software	Alternative Software version
Helm	3	-	-
PostgreSQL	16+	Postgres DB (Platform V Pangolin SE)	6.x.x *
MinIO	Latest *	Ceph	Latest *

* Standard APIs are used

Preparing for installation¶

Distribution structure¶

The distribution directory contains the following main files and subdirectories:

File name	Description
`values.yaml`	A file containing the values of the variables required for deployment. Manual editing of the parameters is required before deployment
`images/solidpoint-backend.tar`	The image of the container with the backend
`images/solidpoint-dashboard.tar`	The image of the container with the dashboard
`images/solidpoint-fuchsiad.tar`	The image of the container with the scanning service
`chart.yaml`	Helm chart metadata file
`templates/`	Manifests directory

Important

Image archives are optional and are not always included in the distribution.
If the previous installation is being updated, it is enough to reuse previously created parameters in values.yaml for databases and for S3 storage. Data structures and schemas will be automatically updated when a new version is launched.
The structure of the values.yaml file may differ in different versions of the distribution.

PostgreSQL databases and S3 storage are typically deployed in advance. If a test deployment is required, follow the guide which uses pre-configured manifests for MinIO and the TimescaleDB extension for PostgreSQL. Deploying databases in Kubernetes is not recommended.

Deploying a database for the scanning service¶

It is necessary to deploy a PostgreSQL-based database for the scanning service with the following list of parameters, then enter the values in the parameters of the values.yaml file:

`values.yaml` parameter	Description
`FUCHSIAD_POSTGRES_SERVER_URL`	Scanning service database URL in the `ip:port` format
`FUCHSIAD_POSTGRES_DB`	Scanning service database name
`FUCHSIAD_POSTGRES_USER`	Username for the scanning service database
`FUCHSIAD_POSTGRES_PASSWORD`	User password
`FUCHSIAD_POSTGRES_SSL_MODE`	Regulates the use of the SSL protocol to connect to the database

Deploying a database for the backend¶

It is necessary to deploy a PostgreSQL-based database for the backend with the following list of parameters, then enter the values in the parameters of the values.yaml file:

`values.yaml` parameter	Description
`BACKEND_POSTGRES_SERVER_URL`	Backend database URL in the `ip:port` format
`BACKEND_POSTGRES_DB`	Backend database name
`BACKEND_POSTGRES_USER`	Username for the backend database
`BACKEND_POSTGRES_PASSWORD`	User password
`BACKEND_POSTGRES_SSL_MODE`	Regulates the use of the SSL protocol to connect to the database

S3 connection parameters for the scanning service¶

Pre-creation of buckets in S3 storage is not required, they are automatically created by the scanner. The parameter values must be assigned to the corresponding parameters of the values.yaml file:

`values.yaml` parameter	Description
`S3_SERVER_URL`	URL of the S3 API interface
`S3_ROOT_USER`	S3 user with bucket creation rights
`S3_ROOT_PASSWORD`	User password

Uploading container images to the corporate image registry¶

Create namespace
```
kubectl create namespace solidpoint
```
Load the three images from the archive into the container runtime environment (image names can be found in the table following step 6).
```
docker load < [имя_образа]
```
Push the images to the corporate registry.
```
docker push [имя_образа]
```
If the corporate registry is only accessible via authentication, you need to create a secret in the namespace where you plan to install the application, for example:

apiVersion: v1
kind: Secret
metadata:
  name: nexus
  namespace: fuchsia
data:
  .dockerconfigjson: [config]
type: kubernetes.io/dockerconfigjson

The name of this secret must be entered in the values.yaml file.

`values.yaml` parameter	Parameters out of the box. Must be changed to the current ones	Description
`imagePullSecrets`	Parameters	The secret to accessing the corporate registry

If the images are intended to be pulled from the vendor's corporate registry, create a secret containing the authentication data (username and password will be supplied with the distribution if necessary).
```
kubectl create secret docker-registry registry --docker-server=repo.solidpoint.net --docker-username=USERNAME --docker-password=PASSWORD -n solidpoint
```
For all three images, edit the contents of the values.yaml file as indicated below:

`values.yaml` parameter	Manufacturer's parameters. They must be changed to the ones relevant for the internal registry	Description
`dashboard.repository`	`repo.solidlab.ru/solidlab-dast/solidpoint-dashboard`	Dashboard image name after uploading to the corporate registry
`dashboard.tag`	`2024-04-15`	Dashboard image tag after uploading to the corporate registry
`backend.repository`	`repo.solidlab.ru/solidlab-dast/solidpoint-backend`	Server part image name after uploading to the corporate registry
`backend.tag`	`2024-04-15`	Server part image tag after uploading to the corporate registry
`fuchsiad.repository`	`repo.solidlab.ru/solidlab-dast/solidpoint-fuchsiad`	Scanner image name after uploading to the corporate registry
`fuchsiad.tag`	`2024-04-15`	Scanner image tag after uploading to the corporate registry

Important

When pre-loading and pulling images via a corporate registry, the default vendor image name and tag need to be replaced with those from your corporate registry.
Once the images are pushed to the corporate registry, the values.yaml parameter values may be replaced with custom values as needed.

Installation in a Kubernetes cluster¶

Deployment using Helm¶

At this stage, the values.yaml file with the current parameters should have already been edited. To deploy on the server, run the command:

helm install fuchsia . -f values.yaml -n solidpoint

Accessibility from an external network¶

Configure Ingress for the solidpoint-dast-dashboard service to make the dashboard accessible. To do this, modify the following fields in the values.yaml file to custom values based on your cluster configuration and requirements.

Parameter	Default	Examples	Description
`dashboard.ingress.enabled`	`false`	`true`, `false`	Enables or disables the creation of the Ingress resource. When set to `false`, access is only available via `kubectl port-forward`
`dashboard.ingress.hostname`	Not specified	`https://solidpoint.example.com`	The address where the dashboard will be accessible. Required if `dashboard.ingress.enabled: true`
`dashboard.ingress.ingressClassName`	Not specified	`nginx`, `traefik`	Specifies which Ingress controller should serve this resource. If not specified, the cluster's default class is used

Environment variables¶

The list of all available environment variables is presented in the table below.

Variable name	Default	Description
`FUCHSIAD_POSTGRES_SERVER_URL`	Not specified	Database server address for the `fuchsiad` scan service in the `host:port` format
`FUCHSIAD_POSTGRES_DB`	Not specified	PostgreSQL database name for the `fuchsiad` scan service
`FUCHSIAD_POSTGRES_USER`	Not specified	PostgreSQL username for the `fuchsiad` scan service
`FUCHSIAD_POSTGRES_PASSWORD`	Not specified	PostgreSQL database password for the scan service `fuchsiad` (used only in the first configuration option)
`FUCHSIAD_POSTGRES_PASSWORD_FILE`	`/tmp/secrets/fuchsiad_db_password`	File path (inside the container) of the PostgreSQL database password for the `fuchsiad` scan service (used only in the second configuration option)
`FUCHSIAD_POSTGRES_SSL_MODE`	`require`	Regulates the use of the SSL protocol to connect to the PostgreSQL database for the `fuchsiad` scan service
`FUCHSIAD_SOCKET_PORT`	`7075`	TCP port address of the `fuchsiad` scan service
`FUCHSIAD_SOCKET_ADDR`	Generated based on the provided namespace	The address that other containers can use to interact with `fuchsiad`
`FUCHSIAD_CONFIG_DIR`	`/etc/fuchsia`	Directory containing the `fuchsiad` scan service configuration files
`FUCHSIAD_OMIT_JOB_LOGS`	`false`	If the value is `true`, the scan service task logs are not passed to standard output or error streams (they are only saved to S3-compatible storage)
`FUCHSIAD_LOGS_FILE`	`/var/log/fuchsia/fuchsiad.log`	If set, the scan service logs are duplicated to the specified file
`FUCHSIAD_CREDENTIALS_FILE`	`/tmp/secrets/fuchsiad`	If set, the file is used as an addition to the `fuchsiad` scan service configuration. This is necessary to store sensitive information separately from the main configuration directory specified by the environment variable `FUCHSIAD_CONFIG_DIR` (for example, in a read-only directory)
`BACKEND_POSTGRES_SERVER_URL`	Not specified	Database server address for the backend in the format `host:port`
`BACKEND_POSTGRES_DB`	Not specified	PostgreSQL database name for the backend
`BACKEND_POSTGRES_USER`	Not specified	PostgreSQL username for the backend
`BACKEND_POSTGRES_PASSWORD`	Not specified	PostgreSQL database password for the backend (used only in the first configuration option)
`BACKEND_POSTGRES_PASSWORD_FILE`	`/tmp/secrets/backend_db_password`	File path (inside the container) of the PostgreSQL database password for the backend (used only in the second configuration option)
`BACKEND_POSTGRES_SSL_MODE`	`require`	Regulates the use of the SSL protocol to connect to the PostgreSQL database of the backend
`BACKEND_STATE_DIRECTORY`	`/tmp/solidpoint-backend`	Directory where the state of the server part is stored
`BACKEND_LISTEN_PORT`	`8085`	The TCP port address of the server part
`BACKEND_ADDR`	Generated based on the provided namespace	The address that other containers can use to interact with the server part
`BACKEND_LOGS_FILE`	`/var/log/solidpoint/solidpoint-backend.log`	If set, the server part logs are duplicated to the specified file
`BACKEND_DATABASE_URI_FILE`	`/tmp/secrets/backend`	If set, the PostgreSQL connection string is read from the file whose path is specified, not from the environment variable
`S3_SERVER_URL`	Not specified	S3-compatible storage server address in the `schema://host:port` format
`S3_ROOT_USER`	Not specified	Access key of the `root` user for the S3-compatible storage (used only in the first configuration option)
`S3_ROOT_USER_FILE`	`/tmp/secrets/s3_root_user`	File path (inside the container) of the access key of the `root` user in the S3-compatible storage (used only in the second configuration option)
`S3_ROOT_PASSWORD`	Not specified	Password of the `root` user for the S3-compatible storage (used only in the first configuration option)
`S3_ROOT_PASSWORD_FILE`	`/tmp/secrets/s3_root_password`	File path (inside the container) of the `root` user's password for S3-compatible storage (used only in the second configuration option)
`S3_NO_CHECK_CERT`	`true`	Regulates whether self-signed server certificates are ignored when using SSL/TLS protocols
`SCAN_REPORT_GENERATOR_ADDR`	Generated based on the provided namespace	The name of the report generator service displayed on the internal network. During deployment it must be changed to the address being used
`SCAN_REPORT_GENERATOR_PORT`	`9090`	The port of the machine on which the report generation service is deployed. It must be changed during the deployment process if a non-default port is used
`SCAN_REPORT_GENERATOR_STATE_DIRECTORY`	`/tmp/solidpoint-scan-report-generator`	Directory where files related to reports are stored
`SCAN_REPORT_GENERATOR_LOGS_FILE`	Not specified	If set, the scan report generation service's logs are duplicated to the specified file
`INTERACTSH_DOMAIN`	Not specified	Domain of the configured interactsh server. Leave it unfilled to use the internal preconfigured interactsh server
`INTERACTSH_TOKEN`	Not specified	Authentication token of the interactsh server. • If authentication of a personal preconfigured interactsh server is set up, specify its authentication token; • If authentication is not set up or an internal interactsh server is used, leave it unfilled
`CHANNEL`	`stable`	Specifies the deb package repository channel
`TOKEN`	Not specified	Token for accessing the deb package repository
`TZ`	`Europe/Moscow`	Sets the time zone