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 https://github.com/golang/go/issues/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