Configuring DataStax Enterprise for Kerberos authentication

Steps for adding the Kerberos authenticator to cassandra.yaml and Kerberos options to dse.yaml.

How to add the Kerberos authenticator to cassandra.yaml and Kerberos options to dse.yaml.

Procedure

  1. On each node, edit the cassandra.yaml file to set the authenticator to the Kerberos Authenticator.
    authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
  2. Make sure the rpc_address and listen_address options in cassandra.yaml are set to the IP address or hostname that matches the hostname in DNS (which is the same as the FQDN (Fully Qualified Domain Name) portion of the service principals created in the earlier step from kadmin). They should not be set to localhost.
    rpc_address: 1.2.3.4
    listen_address: 1.2.3.4
  3. On each node, edit the dse.yaml file and enter the correct Kerberos options.

    The options are located in the kerberos_options section. See the table below.

    kerberos_options:
       keytab: path_to_keytab/dse.keytab
       service_principal: dse/_HOST@REALM
       http_principal: HTTP/_HOST@REALM
       qop: auth
    Kerberos options
    Option Description
    keytab 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.
    service_principal Sets the principals that the Cassandra and DSE Search (Solr) processes run under. Use the form dse/_HOST@REALM, where dse is the service name.

    Leave _HOST as is. This variable is used in dse.yaml. DataStax Enterprise automatically substitutes the FQDN of the host where it runs. Credentials must exist for this principal in the keytab file and readable by the user that Cassandra runs as, usually cassandra.

    The service_principal must be consistent everywhere:
    • dse.yaml file
    • keytab
    • cqlshrc file (where it is separated into the service/hostname)
    http_principal Set REALM to the name of your Kerberos realm. In the Kerberos principal, REALM must be all uppercase.

    Leave _HOST as is. This variable is used in dse.yaml. DataStax Enterprise automatically substitutes the FQDN of the host where it runs. Credentials must exist 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 Wikipedia search demo on a secure cluster.

    qop A comma-delimited list of Quality of Protection (QOP) 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 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 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.

    The location of the dse.yaml file depends on the type of installation:
    Installer-Services /etc/dse/dse.yaml
    Package installations /etc/dse/dse.yaml
    Installer-No Services install_location/resources/dse/conf/dse.yaml
    Tarball installations install_location/resources/dse/conf/dse.yaml
    The location of the cassandra.yaml file depends on the type of installation:
    Package installations /etc/dse/cassandra/cassandra.yaml
    Tarball installations install_location/resources/cassandra/conf/cassandra.yaml
  4. If the cluster will run Hadoop in a Kerberos secure environment, change the task-controller file ownership to root and access permissions to 4750. For example:
    sudo chown root /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller
    sudo chmod 4750 /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller

    Package installations only: The default location of the task-controller file should be /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller.

  5. 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.