Listeners config doesn't accept passwords with special characters

[p53]

Describe the bug
When using password with special chars for truststore/keystore, kafka startup fails, problem is here:

https://github.com/banzaicloud/koperator/blob/master/pkg/resources/kafka/configmap.go#L331

example of non-working password:
listener.name.internal.ssl.truststore.password=e1ztoimKhBWS6IyO\{AlEV3xkuHMs.vr

Steps to reproduce the issue:
in secret used for truststore/keystore use special characters

Expected behavior
using special characters should result in successfull kafka startup

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem like release numberm version, branch, etc.

[bartam1]

Thank you for the report @p53!
Can the problem be on the Kafka side? I mean there is a limitation on what kind of passwords are accepted for this field: listener.name.internal.ssl.truststore.password.
Can you check the kafka broker logs what is the error message?
Can you check the Koperator logs is there any error message?
Can you check the listener.name.internal.ssl.truststore.password field in the configmap of the broker (e.g:kafka-config-0). Does it contain properly your password?
Thank you!

[p53]

@bartam1 i changed config-map manually to this: listener.name.controller.ssl.keystore.password=e1ztoimKhBWS6IyO\\\{AlEV3xkuHMs.vr and that was working but maybe better than slash escaping would be using unicode escape (like here golang/go#39137) probably it would be more safe and reliable, if kafka accepts it, didn't try that. Yes i verified truststore password with keytool and it was e1ztoimKhBWS6IyO\{AlEV3xkuHMs.vr

[p53]

@bartam1 i just tested it, had this password vg\Afj~dKwVhHDZ3P1eIpWar9FzEO&nU and kafka was failing to start, after i base64 encoded unicode escaped password: \u0076\u0067\u005c\u0041\u0066\u006a\u007e\u0064\u004b\u0077\u0056\u0068\u0048\u0044\u005a\u0033\u0050\u0031\u0065\u0049\u0070\u0057\u0061\u0072\u0039\u0046\u007a\u0045\u004f\u0026\u006e\u0055 and changed certificate secret, it works. It's not nice but probably safest and most reliable way

[p53]

@bartam1 you can reproduce it like this:

• secret with stringdata which should contain password field with your password:

---
apiVersion: v1
kind: Secret
metadata:
  name: some-secret
stringData:
  password: e1ztoimKhBWS6IyO\{AlEV3xkuHMs.vr

• create secret for self-signed certificate:

---
apiVersion: v1
kind: Secret
metadata:
  name: some-secret-ca
Data:
  tls.key: ""
  tls.crt: ""

• create cluster self-signed cert-manager issuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-cluster-issuer
spec:
  selfSigned: {}

• create self-signed cert with above:

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-selfsigned-ca
spec:
  isCA: true
  commonName: my-selfsigned-ca
  secretName: some-secret-ca
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-cluster-issuer
    kind: ClusterIssuer
    group: cert-manager.io

• create issuer:

---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
spec:
  ca:
    secretName: some-secret-ca

• create certificate for kafka:

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: kafka-all-broker.kafka.svc.cluster.local
spec:
  secretName: some-secret
  commonName: kafka-all-broker.kafka.svc.cluster.local
  usages:
    - server auth
    - client auth
  dnsNames:
  - '*.kafka-all-broker.kafka.svc.cluster.local'
  issuerRef:
    name: my-issuer
    kind: Issuer
    group: cert-manager.io
  keystores:
    jks:
      create: true
      passwordSecretRef:
        key: password
        name: some-secret
  privateKey:
    encoding: PKCS8

• crd definition where secret is used:

  clientSSLCertSecret:
    name: some-secret
  listenersConfig:
    internalListeners:
      - type: "ssl"
        serverSSLCertSecret:
          name: some-secret
        name: "internal"
        containerPort: 9092
        usedForInnerBrokerCommunication: true
      - type: "ssl"
        serverSSLCertSecret:
          name: some-secret
        name: "controller"
        containerPort: 9093
        usedForInnerBrokerCommunication: false
        usedForControllerCommunication: true

[p53]

checked this even deeper and problem seems to be in java Properties.load function https://stackoverflow.com/a/5785128

[p53]

i think it should be either sanitized somehow or at least made some warning in docu