Authenticating a cluster with Kerberos
DataStax Enterprise authentication with Kerberos protocol uses tickets to prove identity for nodes that communicate over non-secure networks.
This section provides information about configuring security for a DataStax Enterprise (DSE) cluster using Kerberos.
Kerberos is a computer network authentication protocol that allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner using tickets. This section does not provide detailed information on installing and setting up Kerberos. For this information, see the MIT Kerberos Consortium.
For information about using Kerberos with SSL, see Using Kerberos and SSL at the same time. For information about configuring Kerberos in an external Hadoop system, see "Using Cloudera Manager to Configure Hadoop Security" or the Hortonworks documentation.
The following are general guidelines for setting up Kerberos:
- Before installing DSE, set up your Kerberos servers.
- Set up several machines as authentication servers (Key Distribution Center [KDC]). One will be the primary or administration KDC, the others will be secondary.
- Do not install the KDC servers on DSE nodes.
- Set up firewalls on each KDC server.
- Physically protect the KDC machines.
- Secure the keytab files owned by the user running DSE. The file should be readable and writeable only by the owner without permissions for any other user (chmod 0600).
Because JCE-based products are restricted for export to certain countries by the U.S. Export Administration Regulations, DataStax Enterprise does not ship with the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy. DataStax recommends installing the JCE Unlimited Strength Jurisdiction Policy Files:
- Go to the Oracle Java SE download page.
- For Java 6, click Previous Releases > Java Platform Technologies > Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6.
- For Java 7, under Additional Resources, download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files.
- Unzip the downloaded file.
- Copy local_policy.jar and US_export_policy.jar to the $JAVA_HOME/jre/lib/security directory overwriting the existing JARS.
If you choose not to use AES-256, you must remove the AES-256 settings as an allowed cypher for each principal and regenerate the keys for the krbtgt principal. Remove AES-256 settings in one of the following ways:
- If you have not created the principals, use the -e flag to specify encryption:salt type pairs. For example: -e "arcfour-hmac:normal des3-hmac-sha1:normal". This method requires Kerberos 5-1.2 on the KDC.
- If you have already created the principals, modify the Kerberos principals using
the -e flag as described above and then recreate the keytab
file. This method requires Kerberos 5-1.2 on the KDC.
Alternately, you can modify the /etc/krb5kdc/kdc.conf file by removing any entries containing aes256 from the supported_enctypes variable for the realm in which the DSE nodes are members. Then change the keys for the krbtgt principal.
Securing DataStax Enterprise nodes¶
Do not upgrade DataStax Enterprise and set up Kerberos at the same time; see Security Recommendations.
Perform the following 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 as described above.
Use Kerberos to generate one keytab file for each node:
kadmin -p username/admin addprinc -randkey dse/FQDN addprinc -randkey HTTP/FQDN ktadd -k dse.keytab dse/FQDN ktadd -k dse.keytab HTTP/FQDN quit
- -randkey creates a random password.
- ktadd -k creates a keytab for the dse and HTTP principals; -k specifies the keytab file name. In this example, the keytab entry is added to the dse.keytab file in the current directory.
In the cassandra.yaml configuration file, set
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, using the default replication factor of 1 for the system_auth keyspace precludes logging into any secured node.
Set the DSE service principals, keytab location, and qop (Quality of
Protection) in the dse.yaml configuration
kerberos_options: keytab: path_to_keytab/dse.keytab service_principal: dse_user/_HOST@REALM http_principal: HTTP/_HOST@REALM qop: auth
- Set the service_principal that the Cassandra and Hadoop processes run under. It must use the form dse_user/_HOST@REALM, where dse_user is cassandra in package and GUI/Text Services installs (the name of the user running the service) and the name of the UNIX user that starts the service in tarball and GUI/Text No Services installs. It must be consistent everywhere: in the dse.yaml, present in the keytab, and in the cqlshrc file (where it is separated into the service/hostname).
- Set REALM to the name of your Kerberos realm. In the Kerberos principal, REALM must be all uppercase.
- Leave _HOST as is. DSE 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/Solr node, see Running the demo on a secure cluster.
- 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 DSE must also have read permissions on the keytab.
- The qop is a comma delimited list of Quality of
Protection values that clients and servers can use for each connection.
The client can have multiple QOP values, while the server can have only
a single QOP value. The available settings are:
- auth - authentication only [default]
- auth-int - authentication plus integrity protection for all transmitted data
- auth-conf - authentication plus integrity protection and encryption of all transmitted data
For 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
Be sure that the realm name is uppercase.