Technical — Cassandra Monday 12th November 2018

Introducing the Kerberos Authenticator for Apache Cassandra

By Adam Zegelin

Update– As on November 2020 our Kerberos authenticator now supports Apache Cassandra 4.0

Following in the steps of our recently-launched open source LDAP authenticator for Apache Cassandra, today we are happy to announce that we have released an open source Kerberos authenticator, bringing true single sign-on and the industry-leading secure authentication capabilities of Kerberos to Apache Cassandra.

If a Kerberos environment already exists, then configuring a cluster to use the Kerberos authenticator is a straightforward process. A DNS server and a working Kerberos Key Distribution Centre (KDC) are required, and each Cassandra node must be issued a Kerberos service principal, a forward DNS record, and a reverse DNS record.

Each Cassandra node and client application must be able to reach the DNS server and resolve both the forward and reverse DNS records. This is because the GSS-API/Kerberos5 SASL mechanism requires that the SASL servers (the Cassandra nodes) are configured with a fully-qualified hostname. As node discovery in Cassandra is based on the broadcast_rpc_address, the reverse-DNS entries are necessary because they allow the Cassandra nodes and clients to establish the fully-qualified hostname of each node from these IP addresses. Therefore each reverse-DNS entry that should match the value of the broadcast_rpc_address. Note that if broadcast_rpc_address is not set it will default to rpc_address, so the value of rpc_address should be set to something other than localhost.

Once these configuration pre-requisites are met, the installation of the Kerberos authenticator itself is straightforward.

Detailed installation & configuration instructions can be found on the project GitHub.

Java driver

In conjunction with the Cassandra authenticator, we have also published an open-source Kerberos authenticator plugin for the Cassandra Java driver.

The plugin supports multiple Kerberos quality of protection (QOP) levels, which may be specified directly when configuring the authenticator. The driver’s QOP level must match the QOP level configured for the server authenticator, and is only used during the authentication exchange. If confidentiality and/or integrity protection is required for all traffic between the client and Cassandra, it is recommended that Cassandra’s built-in SSL/TLS be used (note that TLS also protects the Kerberos authentication exchange, when enabled).

An (optional) SASL authorization ID is also supported. If provided, it specifies a Cassandra role that will be assumed once the Kerberos client principal has authenticated, provided the Cassandra user represented by the client principal has been granted permission to assume the role. Access to other roles may be granted using the GRANT ROLE CQL statement.

If an authorization ID is not provided, then Cassandra role or user represented by the client principal itself will be assumed. It should also be noted that if a Cassandra user or role matching the client principal (and authorization ID, if provided) does not exist, no access will be granted.

The implementation of the Java driver plugin provides for flexible configuration of the GSS-API mechanism via JAAS. This allows the mechanism by which the client’s credentials are provided to the driver plugin to be specified independently of the implementation. In practice, this means that the authentication material for the client principal may be obtained either from a keytab or from a valid TGT in the local Kerberos ticket cache, as determined by the contents of the JAAS configuration file.

Zero-downtime migration

Migrating an existing cluster to the Kerberos authenticator from another authentication mechanism may be accomplished with zero Cassandra downtime via a rolling restart after the configuration steps are complete. However, please note that client applications must be updated to ensure that they are correctly configured to use the Kerberos authenticator. In order to achieve zero-downtime for client applications during a migration, the application will need to support Cassandra authentication via both mechanisms. This may be achieved by modifying the application so that it attempts to authenticate using the Kerberos authenticator when authentication via the original mechanism fails.

Both the Cassandra authenticator and the Java driver plugin are 100% free to use under the Apache License v2, so head on over to the GitHub page and try it out. The Java driver plugin may be found here. The Kerberos authenticator currently supports Cassandra 3.0.x and 3.11.x branches.

Like the LDAP authenticator, the Kerberos authenticator is included in the support scope for Instaclustr customers with Apache Cassandra Enterprise Support.

Improvements and feedback are welcome. Please feel free to open a pull request or an issue ticket if you discover a bug or have a feature you would like us to include.