Search Security Configuration
This section describes how to configure Search in CDH 5 to enable Kerberos security and Sentry.
Configuring Search to Use Kerberos
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.
- 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
- 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.
- Create keytab files with both
principals.
kadmin: xst -norandkey -k solr.keytab solr/fully.qualified.domain.name \ HTTP/fully.qualified.domain.name
- Test that credentials in the merged keytab file
work. For
example:
$ klist -e -k -t solr.keytab
- 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.
- 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. - If using applications that use the
solrj library, set up the Java Authentication and Authorization Service
(JAAS).
- 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>"; };
- 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.
- 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.
Using Kerberos
- Using Kerberos and curl
- Using solrctl
- Configuring SolrJ Library UsageThis enables technologies including:
- Command line solutions
- Java applications
- The MapReduceIndexerTool
- Configuring Flume Morphline Solr Sink Usage
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/
![](../static/note.jpg)
Using solrctl
If you are using solrctl to manage your deployment in an environment that requires Kerberos authentication, you must have valid Kerberos credentials, which you can get using kinit. For more information on solrctl, see Solrctl Reference.
Configuring SolrJ Library Usage
If using applications that use the solrj library, begin by establishing a Java Authentication and Authorization Service (JAAS) configuration file.
Create a JAAS file:
- If you have already used kinit to get credentials, you can have the
client use those credentials. In such a case, modify your jaas-client.conf file to appear as
follows:
Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=false useTicketCache=true principal="user/fully.qualified.domain.name@<YOUR-REALM>"; };
where user/fully.qualified.domain.name@<YOUR-REALM> is replaced with your credentials. - You want the client application to authenticate
using a keytab you specify:
Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/path/to/keytab/user.keytab" storeKey=true useTicketCache=false principal="user/fully.qualified.domain.name@<YOUR-REALM>"; };
where /path/to/keytab/user.keytab is the keytab file you wish to use and user/fully.qualified.domain.name@<YOUR-REALM> is the principal in that keytab you wish to use.
Use the JAAS file to enable solutions:
- Command line solutionsSet the property when invoking the program. For example, if you were using a a jar, you might use:
java -Djava.security.auth.login.config=/home/user/jaas-client.conf -jar app.jar
- Java applicationsSet the Java system property java.security.auth.login.config. For example, if the JAAS configuration file is located on the filesystem as /home/user/jaas-client.conf. The Java system property java.security.auth.login.config must be set to point to this file. Setting a Java system property can be done programmatically, for example using a call such as:
System.setProperty("java.security.auth.login.config", "/home/user/jaas-client.conf");
- The MapReduceIndexerToolThe MapReduceIndexerTool uses SolrJ to pass the JAAS configuration file. Using the MapReduceIndexerTool in a secure environment requires the use of the HADOOP_OPTS variable to specify the JAAS configuration file. For example, you might issue a command such as the following:
HADOOP_OPTS="-Djava.security.auth.login.config=/home/user/jaas.conf" \ hadoop jar MapReduceIndexerTool
Configuring Flume Morphline Solr Sink Usage
Repeat this process on all Flume nodes:
- If you have not created a keytab file, do so now at /etc/flume-ng/conf/flume.keytab. This file should contain the service principal flume/<fully.qualified.domain.name>@<YOUR-REALM>. See the CDH 5 Security Guide for more information.
- Create a JAAS configuration file for flume at
/etc/flume-ng/conf/jaas-client.conf.
The file should appear as
follows:
Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true useTicketCache=false keyTab="/etc/flume-ng/conf/flume.keytab" principal="flume/<fully.qualified.domain.name>@<YOUR-REALM>"; };
- Add the flume JAAS configuration to the JAVA_OPTS in /etc/flume-ng/conf/flume-env.sh. For example,
you might
change:
JAVA_OPTS="-Xmx500m"
to:JAVA_OPTS="-Xmx500m -Djava.security.auth.login.config=/etc/flume-ng/conf/jaas-client.conf"
Configuring Sentry for Search
![](../static/note.jpg)
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.
Roles and Privileges
Sentry uses a role-based privilege model. A role is a set of rules for accessing a given Solr collection. Access to each collection is governed by privileges: Query, Update, or All (*).
collection=logs->action=Query
engineer_role = collection=hive_logs->action=Query, collection=hbase_logs->action=Query, collection=current_bugs->action=Update
Users and Groups
- A user is an entity that is permitted by the Kerberos authentication system to access the Search service.
- A group connects the authentication system with the authorization system. It is a set of one or more users who have been granted one or more authorization roles. Sentry allows a set of roles to be configured for a group.
- A configured
group provider determines a user’s affiliation with a group. The current
release supports HDFS-backed groups and locally configured groups. For example,
dev_ops = dev_role, ops_role
Here the group dev_ops is granted the roles dev_role and ops_role. The members of this group can complete searches that are allowed by these roles.
User to Group Mapping
You can configure Sentry to use either Hadoop groups or groups defined in the policy file.
![](../static/important.jpg)
To configure Hadoop groups:
![](../static/note.jpg)
OR
To configure local groups:
- Define local groups in a [users] section of the Sentry Configuration File, sentry-site.xml. For
example:
[users] user1 = group1, group2, group3 user2 = group2, group3
- In sentry-site.xml, set search.sentry.provider as
follows:
<property> <name>sentry.provider</name> <value>org.apache.sentry.provider.file.LocalGroupResourceAuthorizationProvider</value> </property>
Setup and Configuration
This release of Sentry stores the configuration as well as privilege policies in files. The sentry-site.xml file contains configuration options such as privilege policy file location. The policy file contains the privileges and groups. It has a .ini file format and should be stored on HDFS.
Sentry is automatically installed when you install Cloudera Search for CDH or Cloudera Search 1.1.0 or later.
Policy File
The sections that follow contain notes on creating and maintaining the policy file.
![](../static/warning.jpg)
Storing the Policy File
Considerations for storing the policy file(s) include:
- Replication count - Because the file is read for each query, you should increase this; 10 is a reasonable value.
- Updating the file - Updates to the file are only reflected when the Solr process is restarted.
Defining Roles
role1 = privilege1 role1 = privilege2
Sample Configuration
This section provides a sample configuration.
![](../static/note.jpg)
Policy File
![](../static/note.jpg)
[groups] # Assigns each Hadoop group to its set of roles engineer = engineer_role ops = ops_role dev_ops = engineer_role, ops_role hbase_admin = hbase_admin_role [roles] # The following grants all access to source_code. # "collection = source_code" can also be used as syntactic # sugar for "collection = source_code->action=*" engineer_role = collection = source_code->action=* # The following imply more restricted access. ops_role = collection = hive_logs->action=Query dev_ops_role = collection = hbase_logs->action=Query #give hbase_admin_role the ability to create/delete/modify the hbase_logs collection hbase_admin_role = collection=admin->action=*, collection=hbase_logs->action=*
Sentry Configuration File
The following is an example of a sentry-site.xml file.
sentry-site.xml
<configuration> <property> <name>hive.sentry.provider</name> <value>org.apache.sentry.provider.file.HadoopGroupResourceAuthorizationProvider</value> </property> <property> <name>sentry.solr.provider.resource</name> <value>/path/to/authz-provider.ini</value> <!-- If the HDFS configuration files (core-site.xml, hdfs-site.xml) pointed to by SOLR_HDFS_CONFIG in /etc/default/solr point to HDFS, the path will be in HDFS; alternatively you could specify a full path, e.g.:hdfs://namenode:port/path/to/authz-provider.ini --> </property>
Enabling Sentry in Cloudera Search for CDH 5
SOLR_AUTHORIZATION_SENTRY_SITE=/location/to/sentry-site.xml SOLR_AUTHORIZATION_SUPERUSER=solr
To enable sentry index-authorization checking on a new collection, the instancedir for the collection must use a modified version of solrconfig.xml with Sentry integration. The command solrctl instancedir --generate generates two versions of solrconfig.xml: the standard solrconfig.xml without sentry integration, and the sentry-integrated version called solrconfig.xml.secure. To use the sentry-integrated version, replace solrconfig.xml with solrconfig.xml.secure before creating the instancedir.
If you have an existing collection using the standard solrconfig.xml called "foo" and an instancedir of the same name, perform the following steps:
# generate a fresh instancedir solrctl instancedir --generate foosecure # download the existing instancedir from ZK into subdirectory "foo" solrctl instancedir --get foo foo # replace the existing solrconfig.xml with the sentry-enabled one cp foosecure/conf/solrconfig.xml.secure foo/conf/solrconfig.xml # update the instancedir in ZK solrctl instancedir --update foo foo # reload the collection solrctl collection --reload foo
If you have an existing collection using a version of solrconfig.xml that you have modified, contact Support for assistance.
Enabling Secure Impersonation
Secure Impersonation is a feature that allows a user to make requests as another user in a secure way. For example, to allow the following impersonations:
- User "hue" can make requests as any user from any host.
- User "foo" can make requests as any member of group "bar", from
"host1" or "host2".Configure the following properties in /etc/default/solr:
SOLR_SECURITY_ALLOWED_PROXYUSERS=hue,foo SOLR_SECURITY_PROXYUSER_hue_HOSTS=* SOLR_SECURITY_PROXYUSER_hue_GROUPS=* SOLR_SECURITY_PROXYUSER_foo_HOSTS=host1,host2 SOLR_SECURITY_PROXYUSER_foo_GROUPS=bar
![](../static/note.jpg)
Debugging Failed Sentry Authorization Requests
- In Cloudera Manager, add log4j.logger.org.apache.sentry=DEBUG to the logging settings for your service through the corresponding Logging Safety Valve field for the Impala, Hive Server 2, or Solr Server services.
- On systems not managed by Cloudera Manager, add log4j.logger.org.apache.sentry=DEBUG to the log4j.properties file on each host in the cluster, in the appropriate configuration directory for each service.
FilePermission server..., RequestPermission server...., result [true|false]which indicate each evaluation Sentry makes. The FilePermission is from the policy file, while RequestPermission is the privilege required for the query. A RequestPermission will iterate over all appropriate FilePermission settings until a match is found. If no matching privilege is found, Sentry returns false indicating
Appendix: Authorization Privilege Model for Search
The tables below refer to the request handlers defined in the generated solrconfig.xml.secure. If you are not using this configuration file, the below may not apply.
admin is a special collection in sentry used to represent administrative actions. A non-administrative request may only require privileges on the collection on which the request is being performed. This is called collection1 in this appendix. An administrative request may require privileges on both the admin collection and collection1. This is denoted as admin, collection1 in the tables below.
Request Handler | Required Privilege | Collections that Require Privilege |
---|---|---|
select | QUERY | collection1 |
query | QUERY | collection1 |
get | QUERY | collection1 |
browse | QUERY | collection1 |
tvrh | QUERY | collection1 |
clustering | QUERY | collection1 |
terms | QUERY | collection1 |
elevate | QUERY | collection1 |
analysis/field | QUERY | collection1 |
analysis/document | QUERY | collection1 |
update | UPDATE | collection1 |
update/json | UPDATE | collection1 |
update/csv | UPDATE | collection1 |
Collection Action | Required Privilege | Collections that Require Privilege |
---|---|---|
create | UPDATE | admin, collection1 |
delete | UPDATE | admin, collection1 |
reload | UPDATE | admin, collection1 |
createAlias | UPDATE | admin, collection1![]() |
deleteAlias | UPDATE | admin, collection1![]() |
syncShard | UPDATE | admin, collection1 |
splitShard | UPDATE | admin, collection1 |
deleteShard | UPDATE | admin, collection1 |
Collection Action | Required Privilege | Collections that Require Privilege |
---|---|---|
create | UPDATE | admin, collection1 |
rename | UPDATE | admin, collection1 |
load | UPDATE | admin, collection1 |
unload | UPDATE | admin, collection1 |
status | UPDATE | admin, collection1 |
persist | UPDATE | admin |
reload | UPDATE | admin, collection1 |
swap | UPDATE | admin, collection1 |
mergeIndexes | UPDATE | admin, collection1 |
split | UPDATE | admin, collection1 |
prepRecover | UPDATE | admin, collection1 |
requestRecover | UPDATE | admin, collection1 |
requestSyncShard | UPDATE | admin, collection1 |
requestApplyUpdates | UPDATE | admin, collection1 |
Request Handler | Required Privilege | Collections that Require Privilege |
---|---|---|
LukeRequestHandler | QUERY | admin |
SystemInfoHandler | QUERY | admin |
SolrInfoMBeanHandler | QUERY | admin |
PluginInfoHandler | QUERY | admin |
ThreadDumpHandler | QUERY | admin |
PropertiesRequestHandler | QUERY | admin |
LogginHandler | QUERY, UPDATE (or *) | admin |
ShowFileRequestHandler | QUERY | admin |
<< ZooKeeper Security Configuration | FUSE - Mountable HDFS Security Configuration >> | |