As I said, Pulsar is not made for cert management system and introducing such extensions will bring a lot of other complexities such as cert rotation, access rights, expiry of certs, securing certs, supporting different types of keystore and cert format etc,.. and that will be out of the scope of Pulsar as a messaging system. If we need such things then make it pluggable same as how we do with encryption key and users can have their custom implementation where users can store certs in any format and at any location (metadata, file-system) but that implementation must be outside of Pulsar repo to avoid scope of this complexity.
Thanks, Rajan On Fri, Sep 8, 2023 at 2:11 AM mattison chao <mattisonc...@gmail.com> wrote: > Hi, Rajan > > I understand your concerns about the cert management. I just want to let > cluster data support store base64 encoded brokerClientTrustCerts to avoid > multiple cluster replication problems in the private cert assignment. We > already have the ClusterDataImpl that stores the metadata. We can easily > expand this entity to support base64 encoded private cert. > > Additionally, apart from the option of retaining the certificate of the > destination cluster, are there any other recommendations you might have in > mind? > > Best, > Mattison > On 8 Sep 2023 at 16:47 +0800, Rajan Dhabalia <rdhaba...@apache.org>, > wrote: > > Hi, > > > > Pulsar stores different types of metadata into a metadata store which > > contains tenant, namespaces and topic metadata. Metadata-store should > store > > metadata definition and should avoid combining other non metadata related > > information especially certificates or keys like encryption/decryption > > keys. Apache Pulsar supports envelope encryption for which it requires to > > store and retrieve encryption keys but if Pulsar starts managing such > keys > > then Pulsar will start playing responsibilities of any other KMS systems > > and that MUST BE out of the scope of the Pulsar because KMS itself is a > big > > beast and it comes with lot of security requirements and > responsibilities. > > And that's why we made it a pluggable component and one can implement its > > own implementation. Similar way, managing certificates MUST be out of > > Pulsar scope else it will become can of worms which comes with lot > security > > bugs and concerns , and definitely it's not something we want to store in > > Metadata store, So, we MUST not introduce a support of cert management in > > Pulsar and MUST NOT store certs into metadata-store, We can certainly see > > if we can provide interface and API to make it pluggable and let users > > manage their own implementation without introducing such critical > > complexities in Pulsar. > > > > Thanks, > > Rajan > > > > On Fri, Sep 8, 2023 at 1:21 AM mattison chao <mattisonc...@gmail.com> > wrote: > > > > > > > > Hello, folks. > > > > > > I hope this email finds you well. I would like to start a discussion > about > > > PIP-296 Support storing broker internal client certificates in metadata > > > store[1]. > > > > > > Please don't hesitate to leave any concerns or questions. > > > > > > Best, > > > Mattison > > > > > > [1] https://github.com/apache/pulsar/pull/21044/files > > > > > > >
