Customizing SonarQube Helm chart before installation
While we only document the most pressing 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 Helm chart:
- By editing the default values in the
values.yaml
file. - Or directly in the Helm chart installation command line (see Installing Helm chart).
To set up SonarQube monitoring, see Setting up the monitoring of a Kubernetes deployment.
Enabling Openshift
If you want to install SonarQube Helm chart on Openshift:
- Set
OpenShift.enabled
tofalse
. - Set
Openshift.createSCC
tofalse
. - If you want to make your application publicly visible with Routes, you can set
route.enabled
totrue
. Please check the configuration details in the Helm chart documentation to customize the Route base on your needs.
Ensuring a restricted security level
About the Pod security level
Below is the Pod security level applied by default to each container. To apply a security level, a default SecurityContext
is set on the container through the Helm chart.
Container | Pod security level | Note |
---|---|---|
SonarQube application containers | restricted | |
SonarQube init containers | restricted | |
postgresql containers | restricted | |
init-sysctl | privileged | Utility software that requires root access. |
init-fs | baseline | Utility software that requires root access. To disable the container, set initFs.enabled in the Helm chart to false . |
The SecurityContext
below is set as default on all restricted containers.
In a Kubernetes installation
To run the SonarQube Helm chart in a full restricted namespace, you must disable the init-sysctl
and init-fs
containers by setting in the Helm chart:
initSysctl.enabled
tofalse
.initFs.enabled
tofalse
.
Since these containers are used to perform some settings at the host/kernel level, disabling them may require additional configuration steps. For more information, see Elasticsearch prerequisites in the Helm chart documentation.
In an OpenShift installation
The configuration described in Enabling OpenShift above forces the disabling of the init-sysctl
and init-fs
containers. These containers should not be required in the vast majority of cases for an Openshift installation. Therefore, an Openshift installation is compatible with restricted SCCv2 (Security Context Constraints).
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
:
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:
- 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.
- Generate the kubernetes secret, e.g. with this command:
k create secret generic --from-file cert.pem <secretName> -n <sonarqubeNamespace>
- In SonarQube’s
value.yaml
file, add:
Creating an Ingress to make SonarQube service accessible from outside
To make the SonarQube service accessible from outside of your cluster, you most likely need an Ingress.
The SonarSource Helm chart has an optional dependency on the NGINX Ingress Helm chart which installs the NGINX Ingress controller (To install the NGINX Ingress Helm chart through SonarQube Helm chart, set ingress-nginx.enabled
to true
in SonarQube’s values.yaml
.). You should use it only in a test environment. In a production environment, it’s highly recommended that you use your own Ingress controller since the controller is a critical part of the software chain.
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.
Was this page helpful?