Adding a new configuration looks good.
Thanks,
Zixuan
Zike Yang 于2023年2月10日周五 15:21写道：
> It looks strange to fill a configuration item named `XXXFilePath` with
> the contents of the key/certs instead of the file path. Maybe adding
> new configs like `brokerClientKey`, `brokerClientCertificate`.
> Is this the same ClusterData object stored in zookeeper?
Sure, it is unsafe, I have the same concern, so I made this issue.
> Would it make sense to add a pluggable supplier that retrieves and
decodes certs? Then, it wouldn't require pulsar code changes for minor
nuances in implementation.
Thi
It looks strange to fill a configuration item named `XXXFilePath` with
the contents of the key/certs instead of the file path. Maybe adding
new configs like `brokerClientKey`, `brokerClientCertificate`... would
be more appropriate.
Thanks,
Zike Yang
Zike Yang
On Fri, Feb 10, 2023 at 2:54 PM
Is this the same ClusterData object stored in zookeeper? If so, it
seems risky to store these certs there because many Pulsar components
access ZK.
I started work to support retrieving in-memory TLS certificates to the
Java Client's ClientConfiguration object [0] but my priorities
changed, and I w
Hi all,
In the ClusterData, we have two types of the key/certificate, one is PEM,
and one is JKS.
I would like to discuss the bae64-encoded key/certificate in PEM format.
The Pulsar can only load the key/certificate by the file path. When
configuring the key/certificate, we must copy the key/cer
