Support for password URI encoding in sql-exporter helm chart

[Darkemust]

Hello, thank you very much for this great helm chart.

Problem detected

I encountered some issues regarding password complexity management in the sql-exporter helm chart in my environment. After trying several options, I don't see a way to correct it based on the options you provide in the helm chart.

I tried modifying the entrypoint but couldn't give up when I checked that I don't have a "command" argument in the helm chart.

Helm chart version: 0.12.5

Environment / Affected drivers

Occurs with complex passwords across DSN construction (containing special characters such as %, >, <, +, etc.) with any database engine.

Configuration (minimal reproduction)

Values.yaml

db-monitoring:
  enabled: true
  podAnnotations:
    reloader.stakater.com/auto: "true"
  fullnameOverride: "db-monitoring"
  envFrom:
    - configMapRef:
        name: db-admin-envs
    - secretRef:
        name: sql-exporter-secrets
    - configMapRef:
        name: cm-dburl
  config:
    global:
      scrape_timeout: 30s
      max_connections: 1
      max_idle_connections: 1
    target:
      collectors: ["db-monitoring"]
      data_source_name: "${SQLEXPORTER_TARGET_DSN}"
    collector_files:
      - "/etc/sql_exporter/collectors/*.collector.yml"
  extraVolumes:
    - name: collector-db
      volume:
        configMap:
          name: cm-collector-db
          items:
            - key: db.collector.yml
              path: db.collector.yml
      mount:
        readOnly: false
        mountPath: /etc/sql_exporter/collectors/

cm-dburl

data:
  {{- if eq .Values.global.database.driver "mysql" }}
  SQLEXPORTER_TARGET_DSN: mysql://{{ .Values.global.database.user }}:${DB_PASS}@{{ .Values.global.database.host }}:{{ .Values.global.database.port }}/{{ .Values.global.database.name }}?tls=skip-verify
  {{- else if (or (eq .Values.global.database.driver "sqlserver") (eq .Values.global.database.driver "jtds-sqlserver")) }}
  SQLEXPORTER_TARGET_DSN: sqlserver://{{ .Values.global.database.user }}:${DB_PASS}@{{ .Values.global.database.host }}/{{ .Values.global.database.name }}
  {{- else if eq .Values.global.database.driver "postgresql" }}
  {{- else if eq .Values.global.database.driver "oracle" }}
  SQLEXPORTER_TARGET_DSN: oracle://{{ .Values.global.database.user }}:${DB_PASS}@{{ .Values.global.database.host }}:{{ .Values.global.database.port }}/{{ .Values.global.database.name }}
  {{- end }}

cm-collector-db

data:
  db.collector.yml: |
    {{- $driver := .Values.global.database.driver | replace "jtds-sqlserver" "sqlserver" }}
    {{- .Files.Get (printf "files/collectors/%s.yaml" $driver) | nindent 4 }}

Impact

Connection attempts fail whenever the password includes characters that must be URI-encoded, causing the DSN to be parsed incorrectly.

Workaround

Manually pre-encode the password and store it as a secret:

printf '%s' '[complex_password]' | jq -s -R @uri

Then reference the encoded value via envFrom and build the DSN using that pre-encoded secret. This works but is not ideal for maintainability.

Expected behavior

• Either the chart encodes the password (or full DSN) safely, or
• The chart exposes a first-class way to provide a prebuilt/encoded DSN (from an existing Secret) without additional templating.

[burningalchemist]

Hey @Darkemust, thanks for pointing this out.

Just for the context, it's currently an expected behaviour by sql_exporter - the special characters if present have to be URL-encoded by the user. I have it in mind (wasn't a big issue before but apparently becomes an annoying piece), and maybe we just address that part in the application itself, so we don't need to fix on the helm chart side.

Let me think about it and I'll get back with an improvement. At the moment I'm a bit busy with my daylight work, but I'll try my best. 👍