Skip to main content

Helm chart configuration

These are some of the most commonly configured settings added to a custom-values.yaml for the deployment of CI Sense Helm charts.

OAuth 2 Login​

authentication:
  github:
    id: ""
    secret: ""
    # ...
  gitlab:
    id: ""
    secret: ""
    ##...
  bitbucket:
    id: ""
    secret: ""
    # ...
  azure:
    id: ""
    secret: ""
  oidc:
    some_name:
      id: ""
      secret: ""
      # ...

Authentication via an OAuth provider is configured in the authentication: section. Refer to the values.yaml for a list of available options.

At least one OAuth provider must be configured for users to log in to CI Sense. See the authentication section in the Code Intelligence documentation for a list of all supported OAuth providers.

Container registry authentication​

global:
  imagePullSecret:
    create: true
    username: "<$USER_NAME>"
    password: "<$PASSWORD>"

Configuring the imagePullSecret with your username and password for the container registry enables kubernetes to pull Docker images from the registry during deployment.

A potentially seperate registry can be configured to store fuzz container images. See the fuzz container registry guide for deployment and configuration options.

Ingress​

ingress:
  hosts:
    gateway: "app.<domain>"
  # tls cert secret provided external to helm chart
  tlsSecretName: cifuzz-server-certificates

grpcIngress:
  host: "grpc.<domain>"
  # tls cert secret provided external to helm chart
  tlsSecretName: cifuzz-server-certificates

Configure the desired ingress endpoints for the HTTP and gRPC endpoints. The ingress: section defines the endpoint that serves the Web App and a REST API and grpcIngress the gRPC endpoint.

Only TLS encrypted communication is allowed with the default values. Creation of a TLS certificate secret is not handled by the helm charts. The client or cluster administrator will likely already have a mechanism to create TLS certificates which can be referenced in the snipped above. Here is how to create the secret manuall using kubectl assuming that we have a cifuzz-server.key and cifuzz-server.crt pair:

kubectl create secret tls cifuzz-server-certificates \
    --namespace <namespace> \
    --key cifuzz-server.key \
    --cert cifuzz-server.crt

More information on how to generate a TLS certificate can be found here.

Shared volume​

## Default values
global:
  pvClaimName: "shared-data"

persistence:
  create: true
  size: 10Gi
  # Restrict to a specific storage class.
  storageClassName: "" # i.e. "ebs-gp3"
  accessModes:
    - ReadWriteMany # Must be RWX when running on multiple nodes.
  # Match a specific persistent volume by labels.
  matchLabels: {}

Both CI Server and CI Worker need access to a shared volume to persist uploaded fuzzer bundles and the fuzzer corpus. With the helm chart deployment a persistent volume claim will be created that is accessed by both the CI Worker and CI Server. The persistent volume claim must be writable from multiple kubernetes nodes (ReadWriteMany). See here for a list of persistent volume classes that support the required access mode. Note that the helm deployment only create the persistent volume claim. An appropriate persistent volume must be created manually for the claim to bind successfully.

You can restrict the claim to a specific volume by matching via kubernetes labels (matchLabels) or the storage class (storageClassName).

Change default passwords​

global:
  # Workers communicating with the Server identify by giving this token, which has to be the same
  # on Server and worker.
  worker_token: "worker-token--change-me"

appConfig:
  # Password for a user that is created during startup.
  ci_demo_org_admin_token: "demo-org-token--change-me"

  # Shared secret to authenticate the gateway and the backend server. It must be at least
  # 32 bytes of hex encoded bytes. If openssl is available you can generate a valid random
  # value with `openssl rand -hex 32`.
  inter_service_auth_key: "dd3a074467aa8b4737ee956d33359beb0eaa1d3f5a142d74220c1f989cded765"

  # Secret key used for session integrity. It must be at least 64 bytes of hex encoded bytes.
  # If openssl is available you can generate a valid random value with `openssl rand -hex 64`.
  ci_auth_server_secret: "ac7fc3b7153c8fce716c48295a73146153be81c30b1811713fbcf35eef79d11c16761ddbbd71919759593bfba9b3a48524808c741ef40b66b8265f218e3850e0"

  # Secret key used to sign JWTs. It must be at least 32 bytes of hex encoded bytes.
  # If openssl is available you can generate a valid random value with `openssl rand -hex 32`.
  jwt_signing_key: "bedf3f6ec5deb7e3d519acf52e0c9a0b2ccdf0fbfa34c652627add4f08004029"

The default values contain some secrets that should be changed for a production deployment.

appConfig:
  # database name
  database_name: "ci_backend"
  # port to access the database
  database_port: "5432"
  # hostname of the database (without port)
  database_address: "<database_address>"
  database_username: "<username>"
  database_password: "<password>"

database:
  # Disable the bitnami/postgresql database.
  enabled: false

Connect to an existing database by specifying the database address, username, and password and disabling the bitnami/postgresql database. It's recommended to use a managed PostgreSQL version 12.7 or later.