Support for TLS configuration

[TristanCacqueray]

trafficstars

It seems like ZK needs a bunch of pkcs or jks files and a keystore password along with this zoo.cfg addition to setup TLS:

 # TLS configuration
secureClientPort=2281
serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
ssl.keyStore.location=/etc/zookeeper-tls/zk.jks
ssl.keyStore.password=${keystore-password}
ssl.trustStore.location=/etc/zookeeper-tls/cacert.pem

sslQuorum=true
ssl.quorum.keyStore.location=/etc/zookeeper-tls/zk.jks
ssl.quorum.keyStore.password=${keystore-password}
ssl.quorum.trustStore.location=/etc/zookeeper-tls/cacert.pem

I guess a couple of options are possible:

• Support a user provided secret with all the information to setup TLS.
• Add a toggle to activate automatic TLS configuration, and the zookeeper-operator would create and manage the secret. Unfortunately, it seems like the cert-manager doesn't support pkcs or jks yet.

Would it possible to add TLS support to the zookeeper service through the zookeeper-operator?

[TristanCacqueray]

Actually it seems like we don't need jks and a keystore password, which may be compatible with what current cert-manager can provide.

[thelabdude]

cert-manager supports pkcs12 now ... I think the approach I took for the Solr operator (which relies heavily on ZK) would be applicable for this operator: https://github.com/bloomberg/solr-operator/pull/151 ... tl;dr is cert-manager integration ... if y'all agree that's a good approach, I can work up a PR for this repo as well

[ravisharda]

Integration with Cert Manager so that Zookeeper can receive TLS material from it, would be a very useful feature to have. It'd simplify the management of TLS material. Presumably, the SSL/TLS certificates (both the server certificate and the CA certificate) and private key files can be provided by Cert Manager. What about the remaining configuration items?

1. The secureClientPort
2. The serverCnxnFactory
3. The file containing the keystore password

I suppose these additional config needs to be provided at deployment-time.

The first two could have some sensible defaults. The admin/operator should be able to configure these at deployment-time. The 3rd one shall require some form of operator input - a Kubernetes secret'd be a nice way of managing that sensitive field.

What do you say?

cc @pbelgundi @fpj

[anishakj]

@thelabdude Do you have any update on this?

[thelabdude]

No update but sounds like there's growing interest in having this, so I can get a PR for it next week (eta: Feb 10) (have another project I need to focus on this week) ~ stay tuned ;-)

[anishakj]

@thelabdude Any further updates?

[dobrerazvan]

Hi, @TristanCacqueray ,

I think there is support for this functionality, we just enabled it on our zookeeper cluster. Using config.additionalConfig map and volumes and volumeMounts, you can enable ssl on a new or existing zookeeper cluster.

Steps:

• convert the pem certs/key in java keystore format (jks) using keytool
• add volumes and volumeMounts zookeepercluster CR config to your cluster config to mount the k8s secret containing the jks file
• use the zoo.cfg configs that you posted in the config.additionalConfigs map in cluster config

Let me know if works for you.

[TristanCacqueray]

@dobrerazvan thanks! We can try to integrate the operator to replace our manual resource definition here. cc @jeblair

[subhranil05]

@dobrerazvan I have followed your steps and tls perfectly working on zk quorum but I have a issue. here it is when implementing tls to zk quorum I'm using 2281 as secureclientport but how can I add this new port permanently to zk-client-service. There is only one client port available now which is 2181 in client service. Is there a scope to use 2181 as secureclientport as it is already clinetport ? Can u help me also on this?