Customizing SonarQube Community Build Helm chart before installation

While we only document the most pressing SonarQube Community Build Helm chart customizations in this documentation, there are other possibilities for you to choose to customize the chart before installing. Please see the Helm chart README file for more information on these. In particular, see the recommended production use case values.

You can customize the SonarQube Community Build Helm chart:

• By editing the default values in the values.yaml file. 
• Or directly in the Helm chart installation command line (see Installing your SonarQube Community Build Helm chart).

Enabling Openshift

If you want to install SonarQube Community Build on Openshift, you must enable Openshift in the Helm chart. In that case:

• The Helm chart will auto-configure itself to comply with the default Openshift SCCs (Security Context Constraints). 
• Not using a default SCC in your Openshift cluster may cause problems.

To enable Openshift in the Helm chart:

1. Set OpenShift.enabled to true.
2. Set Openshift.createSCC to false.
3. If you want to make your application publicly visible with Routes, you can set route.enabled to true. Please check the configuration details in the Helm chart documentation to customize the Route base on your needs.

Ensuring a restricted security level

allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
seccompProfile:
  type: RuntimeDefault
capabilities:
  drop: ["ALL"]

Enabling persistency in Elasticsearch

SonarQube comes with a bundled Elasticsearch, and as Elasticsearch is stateful, so is SonarQube. There is an option to persist the Elasticsearch indexes in a Persistent Volume, but with regular killing operations by the Kubernetes Cluster, these indexes can be corrupted. By default, persistency is disabled in the Helm chart.

Enabling persistency decreases the startup time of the SonarQube Pod significantly, but you are risking corrupting your Elasticsearch index. You can enable persistency by adding the following to the values.yaml:

persistence:
  enabled: true

Leaving persistency disabled results in a longer startup time until SonarQube is fully available, but you won't lose any data as SonarQube will persist all data in the database.

Using custom certificates for your code repository

When you are working with your own Certificate Authority or in an environment that uses self-signed certificates for your code repository platform, you can create a secret containing this certificate and add this certificate to the Java truststore inside the SonarQube deployment.

To add a certificate to the Javatrustore inside the SonarQube deployment:

1. Ask the relevant team to provide you with a PEM format certificate or certificate chain. We will assume it to be called cert.pem on the following commands.
2. Generate the kubernetes secret, e.g. with this command:
   k create secret generic --from-file cert.pem <secretName> -n  <sonarqubeNamespace>
3. In SonarQube’s value.yaml file, add:

caCerts:
  enabled: true
  secret: <secretName>

Creating an Ingress to make SonarQube Community Build service accessible from outside

To make the SonarQube service accessible from outside of your cluster, you most likely need an Ingress.

To create an Ingress resource through the Helm chart:

• Add the following to your SonarQube’s values.yaml. In this configuration, we use the Ingress class NGINX with a body size of at least 64MB since this is what we recommend. 

ingress:
  enabled: true
  # Used to create an Ingress record.
  hosts:
    - name: <Your SonarQube Community Build's FQDN>
      # Different clouds or configurations might need /* as the default path
      path: /
      # For additional control over serviceName and servicePort
      # serviceName: someService
      # servicePort: somePort
  annotations: 
    nginx.ingress.kubernetes.io/proxy-body-size: "64m"