Authenticating a cluster with Kerberos

An overview of Kerberos in DataStax Enterprise and recommendations.

This section provides information about configuring security for a DataStax Enterprise (DSE) cluster using Kerberos.

Attention: The Kerberos Tutorial provides step-by-step instructions on configuring DataStax Enterprise as a Kerberos client. It is intended for anyone interested in enabling Kerberos authentication in DataStax Enterprise and OpsCenter.

DataStax Enterprise authentication with Kerberos protocol uses tickets to prove identity for nodes that communicate over non-secure networks. 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 information on installing and setting up Kerberos, see the MIT Kerberos Consortium.

Note: When using Kerberos security, you need to be aware of the scope of Kerberos tickets. Using the su or sudo command leaves any existing credentials behind and requires you to re-authenticate as that new user. If you encounter authentication issues, ensure that you have a proper Kerberos ticket.

Using Kerberos with DataStax Enterprise

When using audit logging with Kerberos authentication, the login events take place on Kerberos and are not logged in DataStax Enterprise. Authentication history is available only on Kerberos. When DataStax Enterprise is unable to authenticate a client with Kerberos, a LOGIN_ERROR event is logged.

Kerberos guidelines 

The following are general guidelines for setting up Kerberos:

  • Ensure that you are familiar with Kerberos and have reviewed the MIT Kerberos Consortium documentation.
  • You must have authority to set the Kerberos options in the dse.yaml file.
  • Before implementing Kerberos on your DataStax Enterprise nodes, set up your Kerberos servers.
  • Set up several machines as authentication servers (Key Distribution Center [KDC]). One server is the primary or administration KDC, the other servers will be secondary.
  • Do not install the KDC servers on DataStax Enterprise nodes.
  • Set up firewalls on each KDC server.
  • Physically protect the KDC machines.
  • Secure the keytab files that are owned by the user running DataStax Enterprise. The files should be readable and writable only by the owner, without permissions for any other user (chmod 600).

AES-256 support 

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:

  1. Download the Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from 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.
  2. Unzip the downloaded file.
  3. Copy local_policy.jar and US_export_policy.jar to the $JAVA_HOME/jdk/lib/security directory overwriting the existing JARS.

If not using AES-256

If you do not 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.

Note: If the KDC is used by other applications, changing the krbtgt principal's keys invalidates any existing tickets. To prevent this, use the -keepold option when executing the change_password command. For example: 'cpw -randkey krbtgt/krbtgt/REALM@REALM'

Securing DataStax Enterprise nodes 

To secure DataStax Enterprise nodes with Kerberos, follow the steps in Securing DataStax Enterprise nodes with Kerberos.