Configure TLS for Sonarqube via Helm chart

SonarQube Server / Community Build
, ,
1

We are deploying SonarQube community 9.9.0 via helm chart (v. 7.0.2). We are deploying the application to AKS cluster. Everything works smoothly except TLS. We have our TLS certificate secret stored in the same namespace as Sonarqube. During deployment there is no issue with finding this certificate (I was trying to use non-existing secret and it raised the error - which was expected).

Let me try to share the load balancer and ingress configuration below:

service:
  type: LoadBalancer
  externalPort: 443
  internalPort: 9000
  labels:
  annotations: {
    service.beta.kubernetes.io/azure-load-balancer-internal: "true",
    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "aks_nodes-10.182.8.0-24"
  }
  loadBalancerIP: <hardcoded.ip.from.subnet>

nginx:
  enabled: false

ingress:
  enabled: true
  hosts:
  - name: sonar.<company>.com
    path: /
  annotations:
  tls:
  - secretName: sonar-server-tls
    hosts:
    - sonar.<company>.com

Application is now running on http://sonar.<company>.com:443, but there is not TLS certificate loaded. Is the nginx configuration mandatory here? If yes, I was trying just to use the default configuration, so nginx.enabled: true and kubernetes.io/tls-acme: "true" and nginx.ingress.kubernetes.io/proxy-body-size: "64m", ingressClassName: nginx but no success. Could I get any help here please?

5

Hello @fdolsky, thanks a lot for taking the time to participate in the community.

Can you confirm that sonar.<company>.com resolve to the IP of your loadBalancer service ?

Yes the ingress section is mandatory because SonarQube is not able to serve TLS, you need a reverse proxy on top of that.

In kubernetes, the ingress resource is an abstraction of how your app should be served by a reverse proxy.

Nonetheless in vanilla kubernetes cluster, there is no real reverse-proxy deployed capable of processing ingress resources.

So it is a prerequisite from the official ingress documentation here.

the parameter nginx.enabled: true will install nginx-ingress-controller controller for you, nonetheless you are free to install one of your choice.

Ps: that paremeter use nginx helm chart under the hood, you should double check there how to set it up for Azure.

Apart from that, you are right, the secret containing the certificate is declared in the ingress resource, and will later on be picked by the ingress-controller to serve SonarQube with TLS.

Jeremy.

7

I am trying to configure Sonarqube on AKS cluster using a self-signed certificate. My configuration looks as follows.

sonarqube:

service:
type: LoadBalancer
externalPort: 443
internalPort: 9000
nginx:
enabled: true
ingress:
enabled: true
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: “true”
kubernetes.io/ingress.class: “nginx”
nginx.ingress.kubernetes.io/ssl-redirect: “true”
nginx.ingress.kubernetes.io/proxy-body-size: “64m”
hosts:
- name: “sonar..org”
tls:
- secretName: “sonar-secret”
hosts:
- “sonar..org”
auth:
adminPassword: “”
image:
pullPolicy: Always
caCerts:
enabled: true
secret: “sonar-secret”

Error: cannot patch “sonarqube-sonarqube” with kind Ingress: Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io”: failed to call webhook: Post “https://:443/networking/v1/ingresses?timeout=10s”: x509: certificate signed by unknown authority

Any way I can make the configuration work using a self-signed certificate?

8

Please see this section in the SonarQube Helm chart’s documentation for using custom cacerts: https://github.com/SonarSource/helm-chart-sonarqube/tree/master/charts/sonarqube#use-custom-cacerts.