Hi Enrico, I am working on it right now. And thought the community could use it. We can start with it being just role based access but still provide the foundation for read only or more granular access. The role based access part is appealing because anyone with Root CA can access the service even if we have mtls. That is scary because bookkeeper is the main source of truth and storage for many services, even financial services. With this you can deploy BK clusters with only preconfigured whitelist of services that are allowed to talk to it. Assigning roles in the OU field of a certificate is a common practice and using SPIFFE is even state of the art.
This can be configured and switched off by default till all upstream consumers get their key management services to generate certificates with roles. On Thu, May 28, 2020, 12:01 AM Enrico Olivelli <eolive...@gmail.com> wrote: > Anup, > thanks for bringing up this this topic. > > > Il giorno gio 28 mag 2020 alle ore 00:30 Anup Ghatage <ghat...@gmail.com> > ha scritto: > > > Hey everyone, > > > > I see that we have certificate based authentication in this commit > > < > > > https://github.com/apache/bookkeeper/commit/8e0bd2c3d81b522e97434d8646915f36422a104b > > > > > . > > We also provide a extensibility for 'authorization' by implementing our > own > > AuthZ factory which extends bookieAuthProvider. > > However, to implement authorization, we need a configurable role based > > authorization based on certain attributes in the certificates. > > Usually, we've seen this done in 2 days. > > > > 1. Have the role attributes in the 'OU' field of the 'Subject' field of > the > > certificate. > > > > This is a dump of the SUBJECT field from bookkeeper-server/src/test/ > > resources/server-cert.pem > > CN=apache.bookkeeper.org > > O=Dummy > > L=San Francisco > > S=CA > > C=US > > > > 2. Have role attributes using SPIFFE in the Extended SAN's section of the > > certificate. > > Something as simple as the following: > > > > > *spiffe://internal-key-service/v1/service={service}/namespace={namespace}/* > > > > > > *Where service the can be Pulsar brokers, Herddb clients etc, namespace > can > > be cluster name/id. SPIFFE provides extensibility with more levels of > > abstraction that can be added.* > > *Having this sort of certificate based AuthZ will enable us to set > granular > > control on what bookkeeper clients can access, or even something simple > as > > allow read only for certain clients etc.* > > > > > > *I was wondering if we have plans for anything like this or if the > upstream > > consumers are interested in this.* > > > > I don't have plans in this direction, but introducing access control to BK > (at least readonly clients) > looks like an interesting feature. > > Do you already have a custom bookieAuthProvider that implements any of the > proposals above ? > > Cheers > > Enrico > > > > > > > *Regards,* > > > > *Anup* > > >
