Il giorno gio 28 mag 2020 alle ore 15:23 Anup Ghatage <ghat...@gmail.com> ha scritto:
> 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. > Agreed > > This can be configured and switched off by default till all upstream > consumers get their key management services to generate certificates with > roles. > Yes, it should be off by default Enrico > > 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* > > > > > >
