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.
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, please ensure that you have a proper Kerberos ticket.
For information about using Kerberos with SSL, see Using Kerberos and SSL at the same time.
Kerberos Recommendations
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).
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:
- 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/jdk/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:
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
Do not upgrade DataStax Enterprise and set up Kerberos at the same time; see Security Recommendations.
Procedure
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 the
authenticator:
authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
-
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
file:
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 installs (the
name of the user running the service) and the name of the UNIX user that
starts the service in binary 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 Securing a Solr 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.