Securing DataStax Enterprise nodes with Kerberos

Steps for securing DataStax Enterprise nodes with Kerberos.

Do not upgrade DataStax Enterprise and set up Kerberos at the same time; see Security Recommendations.

Prerequisites

Latest version of Oracle Java SE Runtime Environment 7, not OpenJDK. See Installing Oracle JDK.

Procedure

Perform the following steps on every node:

Install the Kerberos client software.
If you are not using the JCE Unlimited Strength Jurisdiction Policy, make sure that your ticket granting principal does not use AES-256.

Use Kerberos to generate one keytab file for each node.

Each node must have its own keytab that is specific to that node and contains only those principals for that node.

kadmin -p username/admin
addprinc -randkey dse_user/FQDN
addprinc -randkey HTTP/FQDN
ktadd -k dse.keytab dse/FQDN
ktadd -k dse.keytab HTTP/FQDN
quit

Parameter	Description
`dse_user`	Installer-Services and Package installations: cassandra Package installations: the name of the UNIX user that starts the service
`FQDN`	The fully qualified domain name of the host where DataStax Enterprise is running.
`-randkey`	Creates a random password.
`ktadd -k`	Creates a keytab for the dse and HTTP principals. The keytab entry is added to the dse.keytab file in the current directory.

For example, your keytabs should look like this when read by klist.

Node1:

$ sudo klist -e -kt /var/tmp/dse.keytab

Keytab name: FILE:/var/tmp/dse.keytab
KVNO Timestamp Principal
---- ---------------- ---------------------------------------------------------
2 29/12/2014 22:03 HTTP/node1FQDN@YOUR_REALM (des3-cbc-sha1)
2 29/12/2014 22:03 HTTP/node1FQDN@YOUR_REALM (arcfour-hmac)
2 29/12/2014 22:03 HTTP/node1FQDN@YOUR_REALM (des-hmac-sha1)
2 29/12/2014 22:03 HTTP/node1FQDN@YOUR_REALM (des-cbc-md5)
2 29/12/2014 22:03 cassandra/node1FQDN@YOUR_REALM (des3-cbc-sha1)
2 29/12/2014 22:03 cassandra/node1FQDN@YOUR_REALM (arcfour-hmac)
2 29/12/2014 22:03 cassandra/node1FQDN@YOUR_REALM (des-hmac-sha1)
2 29/12/2014 22:03 cassandra/node1FQDN@YOUR_REALM (des-cbc-md5)

Node2:

$ sudo klist -e -kt /var/tmp/dse.keytab

Keytab name: FILE:/var/tmp/dse.keytab
KVNO Timestamp Principal
---- ---------------- ---------------------------------------------------------
2 29/12/2014 22:03 HTTP/node2FQDN@YOUR_REALM (des3-cbc-sha1)
2 29/12/2014 22:03 HTTP/node2FQDN@YOUR_REALM (arcfour-hmac)
2 29/12/2014 22:03 HTTP/node2FQDN@YOUR_REALM (des-hmac-sha1)
2 29/12/2014 22:03 HTTP/node2FQDN@YOUR_REALM (des-cbc-md5)
2 29/12/2014 22:03 cassandra/node2FQDN@YOUR_REALM (des3-cbc-sha1)
2 29/12/2014 22:03 cassandra/node2FQDN@YOUR_REALM (arcfour-hmac)
2 29/12/2014 22:03 cassandra/node2FQDN@YOUR_REALM (des-hmac-sha1)
2 29/12/2014 22:03 cassandra/node2FQDN@YOUR_REALM (des-cbc-md5)

In the cassandra.yaml file, set the authenticator as Kerberos:
```
authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
```
Put the keytab file in the directory that is specified in the dse.yaml file.
In the dse.yaml file, set the DataStax Enterprise keytab location, service principals, and qop (Quality of Protection):
```
kerberos_options:
   keytab: path_to_keytab/dse.keytab
   service_principal: dse_user/_HOST@REALM
   http_principal: HTTP/_HOST@REALM
   qop: auth
```
1. The keytab file must contain the credentials for both of the fully resolved principal names, which replace _HOST with the FQDN of the host in the service_principal and http_principal settings. The UNIX user running DataStax Enterprise must also have read permissions on the keytab.
2. Set the service_principal that the Cassandra and Hadoop processes run under.
  Use the form dse_user/_HOST@REALM, where
  - Installer-Services and Package installations: cassandra
  - Package installations: the name of the UNIX user that starts the service
  The service_principal must be consistent everywhere:
  - dse.yaml file
  - keytab
  - cqlshrc file (where it is separated into the service/hostname)
3. For the http_principal, set REALM to the name of your Kerberos realm. In the Kerberos principal, REALM must be all uppercase. Leave _HOST as is.
  
  DataStax Enterprise automatically substitutes the FQDN (Fully Qualified Domain Name) of the host where it runs. There must be credentials for this principal in the keytab file and readable by the user that Cassandra runs as, usually cassandra.
  
  The http_principal is used by the application container, which is tomcat, and used to run Solr. The web server uses GSS-API mechanism (SPNEGO) to negotiate the GSSAPI security mechanism (Kerberos). To set up password authentication for a DSE Search node, see Running the demo on a secure cluster.
4. Set the qop. A comma-delimited list of Quality of Protection values that clients and servers can use for each connection. The valid values are:
  - auth - Default: Authentication only.
  - auth-int - Authentication plus integrity protection for all transmitted data.
  - auth-conf - Authentication plus integrity protection and encryption of all transmitted data.
    Encryption using auth-conf is separate and completely independent of whether encryption is done using SSL. If both auth-conf and SSL are enabled, the transmitted data is encrypted twice. DataStax recommends choosing only one method and using it for both encryption and authentication.
  Example
  
  If the realm name is foo.com and keytab file is in the resources/dse/conf directory:
```
kerberos_options:
   keytab: resources/dse/conf/dse.keytab
   service_principal: cassandra/_HOST@FOO.COM
   http_principal: HTTP/_HOST@FOO.COM
   qop: auth
```
After the cluster is up and running, change the replication strategy and default replication factor for the system_auth keyspace. See Configuring system_auth keyspace replication.

DataStax recommends configuring system_auth keyspaces for fault tolerance (in case of failure). In a multi-node cluster, if the node storing the user data goes down, the default replication factor of 1 for the system_auth keyspace precludes logging into any secured node.