Skip to content

instaclustr/cassandra-kerberos

Repository files navigation

Cassandra Kerberos Authenticator

A GSSAPI authentication provider for Apache Cassandra

Instaclustr

This authenticator plugin is intended to work with the Cassandra Java Driver Kerberos Authenticator plugin for the Cassandra Java driver.

Supported versions:

  • 2.2

  • 3.0

  • 3.11

  • 4.0

  • 4.1

Note
CQLSH integration works only with Cassandra 4.1 and above.
Warning
if you install / configure this authenticator, with open source Cassandra of version less than 4.1, you will not be able to connect through CQL shell anymore as this functionality is not implemented in CQL shell yet. This authenticator is meant to be used only in connection with Java applications for which you need to setup your driver to use Kerberos Java driver, also from Instaclustr.

Build

To build the project, just run mvn clean install.

The project is organised into modules, each module per major Cassandra version. You will find in target of each module for respective Cassandra version:

  • JAR

  • DEB package

  • RPM package

Environment set-up

  1. Ensure that the following pre-requisite systems are configured:

    • A unique DNS record is created for each node (use hostname -f on each node to verify that the DNS FQDN is configured)

    • A reverse DNS record is created for each node, matching the broadcast_rpc_address

    • A Kerberos 5 KDC server is available

    • Kerberos client libraries are installed on each Cassandra node

    • An NTP client is installed & configured on each Cassandra node. Ideally the Cassandra nodes sync with the same time source as the KDC in order to minimise potential time-sync issues.

    • If using Oracle Java, ensure that the Java Cryptographic Extensions Unlimited Strength Jurisdiction Policy Files are installed (not necessary when using OpenJDK or other JRE implementations)

  2. Ensure that the value of rpc_address (and optionally broadcast_rpc_address, if using) in the cassandra.yaml config file is not set to localhost. Reverse-DNS records must be created to match the broadcast_rpc_address. This enables clients to resolve the Kerberos service principal’s hostname from the IP address.

  3. Configure the /etc/krb5.conf Kerberos config file on each node (see here for further details). Below is an example krb5.conf for an EXAMPLE.COM Kerberos realm:

    [logging]
    default = FILE:/var/log/krb5libs.log
    [libdefaults]
     default_realm = EXAMPLE.COM
     dns_lookup_realm = false
     dns_lookup_kdc = false
    [realms]
     EXAMPLE.COM = {
      kdc = kdc.example.com
      admin_server = kdc.example.com
    }
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
  4. For each cassandra node, create a new Kerberos service principal (see here for further details) Note that the service name portion of the principal (cassandra, in this example) must be the same for each node in the cluster, and must also match the SASL protocol name specified when configuring the Cassandra Java driver Kerberos authenticator. The hostname portion of the principal (e.g. node1.mycluster.example.com) must match the DNS entry for each Cassandra node.

    kadmin -q "addprinc -randkey cassandra/node1.mycluster.example.com@EXAMPLE.COM"
    kadmin -q "addprinc -randkey cassandra/node2.mycluster.example.com@EXAMPLE.COM"
    kadmin -q "addprinc -randkey cassandra/node3.mycluster.example.com@EXAMPLE.COM"
  5. Create a keytab for each newly created service principal (see here for further details)

    kadmin -q "ktadd -k /node1.keytab cassandra/node1.mycluster.example.com@EXAMPLE.COM"
    kadmin -q "ktadd -k /node2.keytab cassandra/node2.mycluster.example.com@EXAMPLE.COM"
    kadmin -q "ktadd -k /node3.keytab cassandra/node3.mycluster.example.com@EXAMPLE.COM"
  6. Copy the corresponding keytab file to the Cassandra configuration directory on each node, and set the appropriate access controls

    scp kdc.example.com:/node1.keytab /etc/cassandra/node1.keytab
    chown cassandra:cassandra /etc/cassandra/node1.keytab
    chmod 400 /etc/cassandra/node1.keytab

Install & configure the Kerberos authenticator

  1. Copy the cassandra-krb5.properties file to the Cassandra configuration directory on each node (e.g. /etc/cassandra/conf or /etc/cassandra, based on OS). Set service_principal and keytab to correspond to the service principals and keytabs created in the previous steps.

    service_principal=cassandra/node1.mycluster.example.com@EXAMPLE.COM
    keytab=node1.keytab
    qop=auth
  2. Copy the authenicator jar to the Cassandra lib directory (e.g. /usr/share/cassandra/lib/)

  3. Set the authenticator option in the cassandra.yaml config file.

    authenticator: com.instaclustr.cassandra.auth.KerberosAuthenticator

You may control where to fetch the configuration file from by system property set upon Cassandra startup, for example -Dcassandra.krb5.config=/path/to/conf.properties

In case you are using packages, JAR and conf file is installed into the right place automatically.

CQLSH

To set up CQLSH, you need to insert and modify accordingly your cqlshrc file. To successfully log in, you need to have a valid ticket. How to obtain it is outside this document, but you should see the output similar to this:

[auth_provider]
module=cassandra.auth
classname=SaslAuthProvider
service=cassandra
keytab=/etc/cassandra/cassandra.keytab
mechanism=GSSAPI
qop=auth

After successful login, you should have a ticket granted:

[root@node1 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: root@EXAMPLE.COM

Valid starting       Expires              Service principal
04/01/2022 15:57:59  04/02/2022 15:39:42  cassandra/node1.example.com@EXAMPLE.COM
04/01/2022 15:39:42  04/02/2022 15:39:42  krbtgt/EXAMPLE.COM@EXAMPLE.COM

If you are logged in as root in shell, it will try to log you in Cassandra as root as well, so you need to have the corresponding role in Cassandra before you authenticate. Create your roles beforehand in order to log in after you switch to KerberosAuthenticator in cassandra.yaml.

In case you are Please see status for Instaclustr support status of this project