commit 3a8f4b4d3e762ac24a0563eeaffd068efaab2b81
author Anup Ghatage <ghatageanup@gmail.com> Wed Oct 07 21:22:24 2020 -0700
committer GitHub <noreply@github.com> Thu Oct 08 00:22:24 2020 -0400
tree 4335f36b94a6b6b22e4b261372c95d0b4b5791a9
parent 1ab76145b82d4615592ee4bae1667d7676495a55

Certificate role based authorization in Apache Bookkeeper. (#2429)

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