You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Anup Ghatage <gh...@gmail.com> on 2020/05/27 22:30:33 UTC
Certificate based authorization for bookkeeper client
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.*
*Regards,*
*Anup*
Re: Certificate based authorization for bookkeeper client
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno gio 28 mag 2020 alle ore 15:23 Anup Ghatage <gh...@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 <eo...@gmail.com>
> wrote:
>
> > Anup,
> > thanks for bringing up this this topic.
> >
> >
> > Il giorno gio 28 mag 2020 alle ore 00:30 Anup Ghatage <ghatage@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*
> > >
> >
>
Re: Certificate based authorization for bookkeeper client
Posted by Anup Ghatage <gh...@gmail.com>.
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 <eo...@gmail.com> wrote:
> Anup,
> thanks for bringing up this this topic.
>
>
> Il giorno gio 28 mag 2020 alle ore 00:30 Anup Ghatage <gh...@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*
> >
>
Re: Certificate based authorization for bookkeeper client
Posted by Enrico Olivelli <eo...@gmail.com>.
Anup,
thanks for bringing up this this topic.
Il giorno gio 28 mag 2020 alle ore 00:30 Anup Ghatage <gh...@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*
>