Listeners config doesn't accept passwords with special characters about koperator HOT 6 OPEN

@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

from koperator.

@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

from koperator.

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!

from koperator.

@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

from koperator.

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

from koperator.

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

from koperator.