Certificate role based authorization for Bookkeeper #2354
Assignees
Labels
Comments
Ghatage
changed the title
sijie
pushed a commit
that referenced
this issue
Oct 8, 2020
This feature allows a predefined set of services to be 'whitelisted' to be able to access bookkeeper based on their client certificates. _This feature is disabled by default._
**Motivation**
As BookKeeper and its supported services move to a cloud friendly service based architecture, it becomes of utmost importance to monitor and allow only certain qualified services to be able to access the data in BK.
We have TLS based authentication, however, any service with the rootCA can access Bookkeeper clusters which is not desirable.
**Changes**
To enable if, we have to set 2 configuration options in server config.
1. Set `bookieAuthProviderFactoryClass` config option to use BookieAuthZFactory
`bookieAuthProviderFactoryClass=org.apache.bookkeeper.tls.BookieAuthZFactory`
2. Set `authorizedRoles` to a comma separated list of roles present in client certificates' OU field.
`authorizedRoles=pulsar-broker-1,pulsar-broker-2`
Read further for details on how to implement these in your client certificates and how to wire it up.
So this feature can be broken down into two parts:
Certificate and roles
Server configuration for authorized roles
**Details:**
_Certificate and roles:_
Here is an example of how the SUBJECT field of a final certificate for Apache Pulsar running in the cloud would look like:
CN=apache.bookkeeper.org
O=apache-pulsar
OU=0:pulsar-broker-role;1:cluster-1
L=San Francisco
S=CA
C=US
This shows that this bookkeeper client certificate is owned by the apache pulsar service has the role ‘pulsar-broker-role’ for entities in ‘cluster-1’.
Only those services with pulsar-broker-role should be able to access it.
We can add more fields separated by commas to increase the upstream application clusters to be able to access this bookkeeper cluster.
For example: `OU=0:herddb-readonlyNode,herddb-readwriteNode;1:herddb-cluster2`
Such separation of access based on services is paramount to keeping this secure as many upstream users of BookKeeper are financial institutions, databases and other services.
_Server configuration for authorized roles_
Once we have a certificate whose SUBJECT field has the OU attribute with the roles we want to authorize, on the Bookie side, we need to specify which roles are allowed.
We make this happen by introducing a server configuration option called `authorizedRoles`.
Since we have only static options, this will be set in stone as long as the bookie booted up with it.
If in case we need to change the allowed roles, we’ll need to stop the bookie, update the configuration file and then restart the bookie.
We can have multiple roles which are authorized as the OU field can have multiple comma separated values for roles.
This is a redo of stale PR #2355
Master Issue: #2354
|
Just a comment on the BP itself, it is described as BP-41 but another proposal uses that identifier (BP-41: Separate BookieId from Bookie Network Address). Meanwhile this proposal is not listed on the community site (ref). |
|
closed by #2429 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the master ticket for tracking BP-41.
Even with TLS/mTLS authentication, any other service with rootCA is able to access Bookkeeper which is unacceptable as Bookkeeper is the source or truth.
This feature allows a predefined set of roles to be 'whitelisted' to be able
to access bookkeeper based on their client certificates.
It also introduces a structure for these roles to adhere to in order to scale.
Proposal PR - Link
The text was updated successfully, but these errors were encountered: