Upgrade helm chart from 10.2.1

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • Community EditionVersion 10.2.1 build 78527
  • Helm, OpenShift 4.13
  • upgrade sonarqube to the latest version
  • change chart values, upgrade chart step by step initially to 10.3

**Greetings. I want to upgrade Sonarqube deployed with the helm chart in OpenShift cluster. When I’m trying to basically upgrade chart reusing previous version I have this error failed error:

pods “sonarqube-postgresql-0” is forbidden: unable to validate against any security context constraint: [pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/sonarqube-postgresql]: Forbidden: seccomp may not be set, provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: int64{1001}: 1001 is not an allowed group, spec.containers[0].securityContext.runAsUser: Invalid value: 1001: must be in the ranges: [1000XXXXX, 1000XXXXXX], provider “restricted”
My current values are:

OpenShift:
  enabled: true
  securityContext:
    enabled: false
  volumePermissions:
    enabled: true
    securityContext:
      runAsUser: auto
persistence:
  enabled: true
  size: 5Gi
postgresql:
  persistence:
    size: 5Gi
  serviceAccount:
    enabled: true
    securityContext:
      enabled: false
    volumePermissions:
      enabled: true
      securityContext:
        runAsUser: auto
serviceAccount:
  create: true

I can suppose that it has been affected by changes in 10.3 chart

Update default ContainerSecurityContext, InitContainerSecurityContext and postgresql.securityContext to match restricted podSecurityStandard
Update initFs defaut securityContext to match baseline podSecurityStandard

But I didn’t catch up how to change values correctly. And also now with current values I have user 1001 in postgre container and fsGroup 1001, I’ve added anyuid scc to sonarqube and postrge pod’s service account, but with 10.3 postgre and sonarqube pods couldn’t be created, after rollback to 10.2.1 everything works fine
**

2

Hey there,

Two points:

  1. What version of the Helm chart are you using? Does it align with your target SonarQube version?
  2. You mentioned upgrading “step by step” – it’s worth mentioning that you can upgrade directly from v10.2 to the latest version, v10.5.1
3

I tried with chart version 10.6, then if failed , tried with 10.3 and 10.4, the same error as well

5

I’ll flag this for some experts. This is an area of deployment I don’t know too well.

7

Hello @Ievgen_Provorov, thanks a lot for participating in the community.

From the error log I see the container looks like ‘sonarqube-postgresql-0’ this is the chart dependency that we mark for evaluation only, we strongly advise to use an external/managed database.

Nonetheless, in this case, to troubleshoot your issue further, you should activate all postgresql.**.securityContext and specify either auto or a big number that is in the valid range.

Please take a look at the extended documentation to fine tune it better.

Nonetheless I would like to emphasize that our postgresql dependency is quite outdated and should not be used for production.

Cheers,
Jeremy.

8

Values like

OpenShift:
  enabled: true
route:
  enabled: true
persistence:
  enabled: true
postgresql:
  persistence:
    size: 5Gi
  serviceAccount:
    enabled: true
  securityContext:
  containerSecurityContext:
    seccompProfile: null
    capabilities: null
serviceAccount:
  create: true

initContainers:
  securityContext:
    seccompProfile: null
    capabilities: null

initFs:
  securityContext:
    seccompProfile: null
    capabilities: null

containerSecurityContext:
  seccompProfile: null
  capabilities: null

did the trick and it was possible to update the instance in OpenShift. Basically it rewrites all sections that has been added since 10.3 helm chart. I think there is a conflict between default seccomp Profile in Openshift and desired security context values generated from chart

9

Indeed, when ‘deleting’ the value by putting it empty OpenShift will enforce its own defaults.

The PostgreSQL chart is really for evaluation purposes; we don’t want to be responsible for data handling, database engine upgrades, and other things from within our chart thought dependency.

I’m glad to hear it worked; you can mark the topic as solved if that answers your question.

Regards,
Jeremy.

10

@jeremy.cotineau Thank you very much for your answer, actually this issue related not only with postrgesql container but also with sonarqube container itself cause seccomp profile has been added into it’s security context as well since helm chart version itself. I don’t think that my solution fits best security practices, I will spend some more time investigating in it maybe with openshift community, I think in needed something like new seccomp profile creation in case of openshift deployment, I also understand that OpenShift deployment is a quite rare usecase and it doesn’t affect many customers. If I find something I will post in this thread. Thanks again for your time

2 Likes