Encode your user inputs for curl commands

  • SonarQube version: 10.*
  • Helm chart: 10.2.*

Deployment to Azure Kubernetes Service I was getting stuck on why the admin password was not being updated to the expected value I had in the Azure Key Vault. I found through logs that none of the API calls being done have the user input encoded. So, it takes the literal value for the password, and if that password has an & in it that is being treated as a termination for another parameter query in the URL.

In the helm chart values file I set the adminPasswordSecretName

account:
  adminPasswordSecretName: sonarqbue-admin-password

We use akv2k8s for secret sync from Azure Key Vaults (it does not really matter how the secret is created, just create one with an & in it) so for completeness, the YAML for the akv2k8s objects looks like the following:

apiVersion: spv.no/v2beta1
kind: AzureKeyVaultSecret
metadata:
  name: sonarqube-admin-password
  namespace: sonarqube
spec:
  vault:
    name: kvdev${cluster_env}sekube
    object:
      name: sonarqube-admin-password
      type: secret
  output:
    secret:
      name: sonarqube-admin-password
      dataKey: password
---
apiVersion: spv.no/v2beta1
kind: AzureKeyVaultSecret
metadata:
  name: sonarqube-admin-password-default
  namespace: sonarqube
spec:
  vault:
    name: kvdev${cluster_env}sekube
    object:
      name: sonarqube-admin-password-default
      type: secret
  output:
    secret:
      name: sonarqube-admin-password
      dataKey: currentPassword
---

This results in a Kubernetes secret being created as sonarqube-admin-password with two data keys for password and currentPassword. We collect logs from all pods in our cluster so troubleshooting we found this from the log of the curlimages/curl pod:

POST /api/users/change_password?login=admin&previousPassword=admin&password=4P&bXPEUH2ks123 HTTP/1.1

Even though the Azure Key Vault secret has the password value as being 4P&bXPEUH2ks123, the API call causes the password to be set as just 4P.

All inputs to the API calls should be encoded so this does not happen, and users/customers have the expected value passed properly.

2 Likes

Hi @wsmelton, and welcome to our community!

Sorry for the delay! Yes, that’s a bug. We’ve created a ticket (SONAR-21136) to track it.

Thanks for reporting!