Streamlining SonarQube Management in Kubernetes With the SonarQube Operator

Have you ever dreamed of fully automated and parameterized SonarQube in your workflow? We will tell you how to achieve this.

SonarQube is a well-known code review tool, especially among developers, for its capability to analyze written code and provide suggestions to improve it.

The use of SonarQube implies lots of manual work. Once you deploy your SonarQube instance, you must create a user, grant specific permissions, and create loads of resources on the user’s behalf, such as rules, secrets, quality gates, etc. But what if your structure has grown so widely that managing all these resources becomes overly complicated? And what if your infrastructure crashes, and you need to recover the SonarQube state by manually doing all this configuration stuff? In these cases, you will prefer your SonarQube to be as resilient and automated as possible.

Why SonarQube Operator?

We introduce you to SonarQube Operator, designed to simplify integrating and maintaining your SonarQube instance within a Kubernetes Operator. You can examine it on our GitHub repository or OperatorHub.

Our solution allows users to manage SonarQube resources by changing their custom resources, whereas the GitOps approach enables users to manage these configurations using Git provider. This is the case where the SonarQube Operator comes in handy. Using the SonarQube Operator also accelerates the SonarQube deployment procedure, especially if you already have a ready-to-go configuration in place.

We highly recommend using the SonarQube Operator as it simplifies SonarQube instance configuration. Our operator is beneficial when you need to make significant configuration changes while preserving the entire history of your system’s state in a secure location.

Installing SonarQube Operator

Before you use the SonarQube Operator, you must deploy it in your cluster. Visit the Operator Hub page for guidelines on installing the SonarQube Operator in your cluster. To access step-by-step installation instructions, click the Install button. Our operator has been tested and verified for stability with the LTS SonarQube version 9.9.1, and we are actively working on providing further support.

The installation of the SonarQube Operator is straightforward. It doesn’t require any particular prerequisites or complex parameter settings. Additionally, the operator’s logic remains highly comprehensive, with no hidden subtleties:

CustomResources and sonar-operator

As shown in the image above, you can manage different components of SonarQube (Users, Groups, Permission Templates, Quality Profiles, Quality Gates)using CustomResources. The kind: Sonar custom resource establishes a connection between the instance and the operator, so you must provide credentials (spec.secret) to manage the required resources:

apiVersion: edp.epam.com/v1alpha1
kind: Sonar
status:
  connected: true
  processedSettings: >-
    sonar.auth.oidc.clientId.secured,sonar.auth.oidc.enabled,sonar.auth.oidc.groupsSync.claimName,sonar.auth.oidc.issuerUri,sonar.core.serverBaseURL,sonar.dbcleaner.hoursBeforeKeepingOnlyOneSnapshotByDay
  value: GREEN
spec:
  defaultPermissionTemplate: edp-default
  secret: sonar-admin-password
  settings:
    - key: sonar.dbcleaner.hoursBeforeKeepingOnlyOneSnapshotByDay
      value: '20'
    - key: sonar.auth.oidc.enabled
      value: 'true'
    - key: sonar.auth.oidc.issuerUri
      value: https://keycloak.example.com
    - key: sonar.auth.oidc.clientId.secured
      value: sonar
    - key: sonar.core.serverBaseURL
      value: https://sonar.example.com/
    - key: sonar.auth.oidc.groupsSync.claimName
      value: roles
  url: https://sonar.example.com/

Integrating SonarQube Operator

After deploying the SonarQube Operator, it is time to establish a connection between the operator and the SonarQube instance.

The integration process involves two steps:

1. Create a secret for the admin user.

2. Craft the “Sonar” custom resource that refers to the admin secret.

The administrator secret should contain a username and password. Create the secret using the command below:

kubectl create secret generic sonar-demo-admin \
  --namespace=sonar-demo \
  --from-literal=password=<admin-password> \
  --from-literal=user=<admin-user>

Create the “Sonar” custom resource that contains the administrator secret mentioned above:

apiVersion: edp.epam.com/v1alpha1
kind: Sonar
metadata:
  name: sonar-demo
spec:
  url: https://sonar.example.com
  secret: sonar-demo-admin
  defaultPermissionTemplate: demo-template
  settings:
    - key: sonar.dbcleaner.hoursBeforeKeepingOnlyOneSnapshotByDay
      value: "20"

Apply the “Sonar” custom resource:

kubectl apply -f Sonar.yaml -n sonar-demo

As a result, you will gain access to the SonarQube service using the credentials stored in the “sonar-demo-admin” secret created earlier.

Manage Operator

Now, you can manage your SonarQube using the SonarQube Operator. To realize the SonarQube Operator’s effectiveness, let’s compare the use of the operator and SonarQube UI. Let us demonstrate how our quality profiles look. Pay attention to the number of rules for each language:

Quality Profiles list

Most of our quality profiles contain over one hundred rules. Is it fascinating to manually create and manage all of them each time you deploy a new SonarQube? Store your rules in the SonarQualityProfile manifest file and apply them when needed. It expedites configuring SonarQube, no matter how many instances you need to deploy. If something happens to the SonarQube instance and a rollback is required, you can reapply the manifest file, and that’s it.

As another example, let’s create a new user in two ways: using UI and using the SonarQube Operator.

To create a user using UI, you must log in as an `Administrator` user, navigate to Administration -> Users -> Create user, and fill in the required fields. Then, you need to add it to the group manually. All these things imply plenty of manual work. These steps remain constant regardless of how many users you have created. Eventually, this process becomes time-consuming.

In SonarQube Operator, users are created by the “SonarUser” custom resource. The custom resource requires you to provide the secret containing user credentials. Unlike the admin user credentials, the common user secret contains only a password, although it can also contain a username and email address as optional fields:

kubectl create secret generic sonar-demo-user \
  --namespace=sonar-demo \
  --from-literal=password=<set_password>

The template of the “SonarUser” custom resource is shown below:

apiVersion: edp.epam.com/v1alpha1
kind: SonarUser
metadata:
  name: sonar-demo-user
spec:
  secret: sonar-demo-user
  login: sonardemouser
  name: sonar-demo-user
  email: demo-email@email.com
  groups:
    - sonar-administrators
  permissions:
    - scan
  sonarRef:
    name: sonar-demo

Apply the “SonarUser” resource:

kubectl apply SonarUser.yaml -n sonar-demo

The outcome? A new user is added to the SonarQube UI’s roster:

Created SonarQube user

In this manner, you can easily replace the fields in the .yaml file and then apply it. You can even duplicate the contents to create multiple users simultaneously, which saves time.

Brief Summary

As demonstrated, the existence of a Kubernetes Operator for deploying and managing SonarQube is a game-changer, sparing users from the tedium of configuring custom resources and crafting Quality Gates to maintain the integrity of application code. Furthermore, it streamlines the effortless restoration of SonarQube to its desired state, thanks to the inherent capabilities of the GitOps approach. With the SonarQube Operator seamlessly integrated into your Kubernetes cluster, you are well-positioned to unlock the full potential of SonarQube. You can also pay attention to our Keycloak Operator if you consider using Keycloak in your infrastructure.