pravega / zookeeper-operator

Kubernetes Operator for Zookeeper
Apache License 2.0
369 stars 205 forks source link

Support for TLS configuration #141

Open TristanCacqueray opened 4 years ago

TristanCacqueray commented 4 years ago

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:

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

TristanCacqueray commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@thelabdude Do you have any update on this?

thelabdude commented 3 years ago

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 commented 3 years ago

@thelabdude Any further updates?

dobrerazvan commented 2 years ago

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:

Let me know if works for you.

TristanCacqueray commented 2 years ago

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

subhranil05 commented 1 year ago

@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?