...

We want to secure BookKeeper clusters, so at least we have to cover this main issues:

• SSL/TLS support for encrypting comunications and/or to implement client authentication
• Use ACLs while writing to ZooKeeper
• Provide an extensible Authentication framework (in BookKeeper 4.4.0 there is already partial support for this)
  • Provide a out-of-the box plugin which implements standard SASL authentication, with at least support for GSSAPI/Kerberos and DIGEST-MD5 mechs
• Provide initial support for Authorization
• SSL/TLS support for encrypting comunications and/or to implement client authentication

Proposals

Major concers are about protocol compatibility, data encryption, configuration on Bookie side and client-side, rolling upgrades and ZooKeeper security.

...

ISSUE: can we drop the 'extensions' line on the definition of AuthMessage in BookkeeperProtocol.proto ?

this message

message AuthMessage {
    required string authPluginName = 1;
    extensions 1000 to max;
}

will become

message AuthMessage {
    required string authPluginName = 1;
    required bytes  token = 2;
}

Rolling upgrade to switch from authentication types:

...

1) when no auth is configured on bookie-side the default "AuthDisabledPlugin" plugin comes to play (on 4.4.0 we call it  "NULLPlugin" )

2) when no  auth is configured on bookies the bookie goes to a permissive mode in which any client is allowed to connect and use bookie functions, any 'auth' message will be answered with an OK status code from the AuthDisabledPlugin

...

ISSUE:  On ZookKeeper the SASL mechanism is decided upon the type of JAAS Subject, this is very simply from admin to be configured. We should make the configuration more explicit, something like a configuration property sasl.mech=GSSAPI|DIGEST-M5.....

SSL/TLS Support

The initial proposal is enable TLS support using the StartTLS mechanism, this way Bookie will continue to advertise only one network endpoint, which in turn is effectively used as Bookie ID.

Having a Bookie with more than one endpoint will need more metadata refactoring, the StartTLS proposal let us skip this change for this version.

In order to support TLS we have to implement TLS comunications on Netty 3 (maybe on Netty 4) and add a new protocol message to implement the StartTLS.

We can implement an AuthPlugin which will use the Certificate sent from the client and attach it to the server-side connection peer.

We can add an optional scheduled task which checks certificate validity, this can be done inside the AuthPlugin, but the AuthPlugin will need to hold a reference to an "handle" to the underlying connection, in order to shutdown it in case of certificate expiration

In order to support such a Connection Handle the PeerInfo structure passed to the AuthPlugin should be changed and become an active object

class ServerSideConnectionHandle {
     SocketAddress remoteAddress;
     List<Object> principals;
     void closeConnection();
}

The SSL Authentication plugin will retain references to every authenticated connection and we need to be handle carefully such references in order not to get into resource leaks

 TBD

Action

...