Cloudera Search supports Kerberos authentication. All necessary packages are installed when you install Search. To enable Kerberos, create principals and keytabs and then modify default configurations.

The following instructions only apply to configuring Kerberos in an unmanaged environment. Kerberos configuration is automatically handled by Cloudera Manager if you are using Search in a Cloudera managed environment.

To create principals and keytabs

Repeat this process on all Solr server nodes.

1. Create a Solr service user principal using the syntax: solr/<fully.qualified.domain.name>@<YOUR-REALM>. This principal is used to authenticate with the Hadoop cluster. where: fully.qualified.domain.name is the host where the Solr server is running YOUR-REALM is the name of your Kerberos realm.

   $ kadmin
   kadmin: addprinc -randkey solr/fully.qualified.domain.name@YOUR-REALM.COM

2. Create a HTTP service user principal using the syntax: HTTP/<fully.qualified.domain.name>@<YOUR-REALM>. This principal is used to authenticate user requests coming to the Solr web-services. where: fully.qualified.domain.name is the host where the Solr server is running YOUR-REALM is the name of your Kerberos realm.

   kadmin: addprinc -randkey HTTP/fully.qualified.domain.name@YOUR-REALM.COM

     Note:

   The HTTP/ component of the HTTP service user principal must be upper case as shown in the syntax and example above.

3. Create keytab files with both principals.

   kadmin: xst -norandkey -k solr.keytab solr/fully.qualified.domain.name \
   HTTP/fully.qualified.domain.name

4. Test that credentials in the merged keytab file work. For example:

   $ klist -e -k -t solr.keytab

5. Copy the solr.keytab file to the Solr configuration directory. The owner of the solr.keytab file should be the solr user and the file should have owner-only read permissions.

To modify default configurations

Repeat this process on all Solr server nodes.

1. Ensure that the following properties appear in /etc/default/solr and that they are uncommented. Modify these properties to match your environment. The relevant properties to be uncommented and modified are:

   SOLR_AUTHENTICATION_TYPE=kerberos
   SOLR_AUTHENTICATION_SIMPLE_ALLOW_ANON=true
   SOLR_AUTHENTICATION_KERBEROS_KEYTAB=/etc/solr/conf/solr.keytab
   SOLR_AUTHENTICATION_KERBEROS_PRINCIPAL=HTTP/localhost@LOCALHOST
   SOLR_AUTHENTICATION_KERBEROS_NAME_RULES=DEFAULT
   SOLR_AUTHENTICATION_JAAS_CONF=/etc/solr/conf/jaas.conf

     Note: Modify the values for these properties to match your environment. For example, the SOLR_AUTHENTICATION_KERBEROS_PRINCIPAL=HTTP/localhost@LOCALHOST must include the principal instance and Kerberos realm for your environment. That is often different from localhost@LOCALHOST.
2. If using applications that use the solrj library, set up the Java Authentication and Authorization Service (JAAS).
   1. Create a jaas.conf file in the Solr configuration directory containing the following settings. This file and its location must match the SOLR_AUTHENTICATION_JAAS_CONF value. Make sure that you substitute a value for principal that matches your particular environment.

      Client {
        com.sun.security.auth.module.Krb5LoginModule required
        useKeyTab=true
        useTicketCache=false
        keyTab="/etc/solr/conf/solr.keytab"
        principal="solr/fully.qualified.domain.name@<YOUR-REALM>";
      };

3. To use short principal names:
   • For Search 1.x: Appendix C - Configuring the Mapping from Kerberos Principals to Short Names in the CDH 4 Security Guide.
   • For Search included with CDH 5: Configuring the Mapping from Kerberos Principals to Short Names in the CDH 5 Security Guide.

Secure Solr requires that the CDH components that it interacts with are also secure. Secure Solr interacts with HDFS, ZooKeeper and optionally HBase, MapReduce, and Flume. See the CDH 5 Security Guide or the CDH 4 Security Guide for more information.

Using Kerberos and curl

You can use Kerberos authentication with clients such as curl. To use curl, begin by acquiring valid Kerberos credentials and then execute the desired command. For example, you might use commands similar to the following:

$ kinit -kt username.keytab username
$ curl --negotiate -u: foo:bar http://solrserver:8983/solr/

  Note: Depending on the tool used to connect, additional arguments may be required. For example, with curl, --negotiate and -u are required. The username and password specified with -u is not actually checked because Kerberos is used. As a result, any value such as foo:bar or even just : is acceptable. While any value can be provided for -u, note that the option is required. Omitting -u results in a 401 Unauthorized error, even though the -u value is not actually used.

Sentry enables role-based, fine-grained authorization for Cloudera Search. Follow the instructions below to configure Sentry under CDH 4.5 or later or CDH 5. Sentry is included in the Search installation.

  Note: Sentry for Search depends on Kerberos authentication. For additional information on using Kerberos with Search, see Configuring Search to Use Kerberos and Using Kerberos.

Note that this document is for configuring Sentry for Cloudera Search. To download or install other versions of Sentry for other services, see:

• Setting Up Search Authorization with Sentry for instructions for using Cloudera Manager to install and configure Hive Authorization with Sentry.
• Impala Security for instructions on using Impala with Sentry.
• Sentry Installation to install the version of Sentry that was provided with CDH 4.
• Sentry Installation to install the version of Sentry that was provided with CDH 5.